在过去，基础设施部署与应用程序更新一直是延缓开发生命周期的两大主要障碍。时至今日，云计算的蓬勃发展让企业用户得以将以往需要耗时数月的资源配置工作在几分钟内完成，因此也给应用程序的生命周期带来了相应改变。话说回来，虽然DevOps确实能够帮上大忙，但只有以超越“文化转变”的角度积极拓展才能真正让这种新方案实现持续部署。
正如我在上一篇专题文章中所说，很明显云计算给应用程序带来更多可能性、强制性以及巨大变化。通过那篇文章，我把重点放在了技术变化的探讨方面，评述云计算对应用程序架构造成的影响——相信大家已经感觉到，如今的应用程序架构开始把支持不断提高的规模与负载变化、更强烈的性能需求以及由云计算引发的定价模式转变纳入设计思路当中。
但当时我并没有谈及云计算所颠覆的另一种传统应用程序要素，也就是应用程序生命周期。具体而言，云计算需要与更为迅捷的应用程序管理节奏相匹配，而这将迫使IT部门作出相应调整。
从表面上看，我们可能很难理解为什么云计算所带来的技术能力会对IT部门及其运作流程产生影响。但是，云计算通过技术能力所带来的关键性基础——也就是自动化特性——必然要求更快的应用程序生命周期与之相匹配。
云计算给IT部门——而非基础设施——带来压力
在云计算出现之前，技术团队完全可以悠哉悠哉地创建应用功能并将其交付到管理者手中，快一点或者慢一点都不是什么大问题。在这种情况下，底层基础设施资源将承受巨大压力，因为快速改进应用程序功能并针对生产环境进行频繁更新成为保障运作流程的前提。由于采购、安置以及配置基础设施所耗费的时间太过漫长，因此应用程序开发以及部署所带来的周期几乎不会成为主要矛盾。换句话来说，基础设施方面的难题将应用程序周期掩盖掉了。
云计算的自动化特性将全部基础设施矛盾消弭于无形。时至今日，我们只需要花上几分钟时间、就能获得大量全新计算资源——这在过去根本无法想象，那时候让全新基础设施资源投入运作通常要花费数周乃至数月时间。很明显，目前基础设施配置所需要的具体时长取决于IT部门的执行流程，而不再受制于底层基础设施资源本身。
与此同时，数字化信息正越来越多地与主流业务产品相集成。以接入互联网的Nest恒温装置为例，这类产品意味着业务执行的实际效果开始高度依赖于应用程序功能可用性的交付速度。没有了基础设施带来的局限，现在的主要障碍已经转变为应用程序生命周期本身。因此，我们可以预见，下一阶段的主要矛盾将由云计算与应用程序开发及部署流程的错位所引发。简而言之，IT部门必须加快应用程序生命周期。
面对这样的矛盾，DevOps粉墨登场。这个混合词将“开发（Development）”与“运营（Operations）”杂糅于一处，代表着原本彼此独立的各组织与流程正式走向融合。这个新名词所代表的愿景在于由精简化、集成化组织通过联合运营流程对应用程序更新进行加速，从而将过去需要数周乃至数月才能完成的应用生命周期缩减至如今的数小时或者最多数天。
但DevOps要如何才能为我们带来神奇的提升效果？
文化转变是必要的，但单凭这一点还远远不够
文化转变是我们经常听到的解决方案之一。从这个角度出发，开发人员与系统管理员通过加入同一团队的方式彼此协作，从而加强联动效果、最终加快应用程序生命周期。
我个人对这类方案并不太看好。没错，开发与运营体系之间往往存在矛盾，而让双方工作人员身处同一团队无疑能够改善人际关系。平心而论，这类方案确实有可能通过促进合作、减少指责来推动当前工作状态。然而从科学层面分析，我们很难确切证实改善人际关系与加快应用程序功能发布周期之间的必要联系。
在任何情况下，渐进式改善都还远远不够。企业没办法仅仅依赖20%的功能构建效率增幅保证自身在未来数字化业务环境下取得成功。因为在这种情况下，实际效果只能是将项目的开发周期由过去的21天缩短为现在的18天，或者举个更常见的例子，由原本的六个月缩短至五个月。要在如今的激烈竞争中保持优势，业务流程的速度提升至少要达到200%才算合格。
另外，“文化”这一表述也属于一种误导。文化关注的是人为因素而非流程——这相当于对流程的一种颠覆。再有，即使速度有所加快，流程本身也需要真正贯穿应用程序生命周期始终才能带来确切成效。
也就是说，我们已经在软件工程层面上取得了重大进展。在过去十年当中，开发实践、灵活的工作方式、频繁登记以及自动化机制的建立与测试已经带来了非常可观的加速效果。这场被称为“持续集成”的革命帮助我们缩短开发周期、降低项目事故并使整个项目流程更具可预测性。
不过对于多数IT部门而言，在谈到将新代码投入生产体系当中时，应用程序生命周期的加速步伐往往就此戛然而止。在实际运营情况下，由于每个下游团队都需要利用自己选择的工具进行任务处理，因此各个环节往往都需要以手动方式进行一次又一次冗余操作——这就破坏了流程的自动化属性。
惟一的解决方式在于保证IT部门实现持续部署，在这种情况下代码修改将贯穿整个自动化应用程序生命周期始终，业务流程快速响应所带来的稳定性影响以及频繁的功能更新也将得到解决。作为负面影响，持续集成会助长IT部门对于自主解决方案的信心，导致业务部门难以将应用程序供应商引入整个运营体系当中。
我曾经听说过很多围绕持续部署所展开的争论。他们的核心分歧在于恶意代码进入生产环境的可能性，以及在执行终端到终端自动化机制后恶意软件所将引发的严重后果。说到底，这场争论的实质在于，如果没有人为因素的干预、自动化流程会出现问题。
我们姑且不谈这样的结论到底跟废话有什么区别，其实根据我的个人经验，就算存在人为干预、问题也照样有可能出现。更进一步，人为干预也可能成为引发问题的诱因，因此我对这样的说辞并不买账。在任何情况下，对于手动执行流程的要求最终都会被用户需求所否决。一味坚持既定方法将是完全徒劳的。如果不相信，大家可以问问VMware的系统管理员——由于他们要求开发人员等待数周的审批来使用虚拟巨头的内部资源，这些开发者直接把自己的虚拟机交给了Amazon Web Services。
持续部署需要自动化、集成化与均衡的激励机制
为了实现持续部署流程，必须满足以下四点前提条件。
一套简洁的自动化流程。如果流程当中包含由审计委员会设定的阶段性目标、未经批准无法进入下一步执行环节或者其它形式的人为监督机制，那么整个体系的运作效率必然大打折扣。虽然我们主张将特定变更划分在自动化流程之外——可能出于复杂性或者其它特定因素的考量，但这与将全部变更都纳入人为干扰范畴完全不同。最理想的方式是在必要情况下引入人为干预因素，但除此之外的常规变更都由自动化流程打理。
一套集成化、终端到终端工具链。很明显，除非整个流程都拥有理想工具作为底层支持，否则自动化工作流程根本就是纸上谈兵。从本质上讲，这些工具在某一阶段中的输出内容都要能够为下一阶段的工具所接纳，也就是说各类工具之间能够顺畅衔接。时至今日，我们完全可以在大型厂商手中直接购买昂贵的专有产品、也能够以开源组件为基础自主构建适合实际需求的功能集合。任何一种方案都既有长处、也有短板。随着这一领域重要性的日益增加，市场对其的关注程度也将水涨船高，相信更多更灵活也更加实惠的解决方案很快就会出现在市场当中。
共享化应用程序构件。新增工具所采用的构件必须能够与整个体系顺利对接。由此带来的可执行文件以及配置创建工作，甚至包括制定自动运行说明在内，都有可能引发潜在的出错风险，进而对功能的快速可用性产生影响。相比之下，最理想的处理方式是利用单一构件集贯穿整个流程，并通过加减权限划分出适合需求的组织结构。
在整个企业内保证指标与激励机制均衡。说到激励机制，我们再次回到了“文化”这一话题上来。如前面提到，我个人并不太相信仅仅通过发展人际关系就足以将不同群体团结在一起、甚至彻底消除协作中的摩擦与失误。要真正实现这样的效果，均衡的评比指标与激励机制才是重中之重。如果我们以功能更新的发布频率作为某个团队的评比标准、却通过运行稳定性作为另一个团队的评比标准，那么双方将由于不具可比性而出现绩效考核方面的冲突。
我们需要通过一系更措施将每一位成员紧密团结在一起。千万别以为将前面提到的各类指标一股脑塞进来就能获得理想的收效，事实上要求同一个团队既能频繁推出更新、又保证成果的运行稳定性，这本身就会引发严重不满——很明显，这样的目标需要由多个团队协作才有可能实现。
当然，以上这些建议也存在一定弊端。其中最主要的问题是它们难于实现，同时也会给现有流程带来极大颠覆。是的，如果我们生活在十年前的IT世界中，那么根本没必要采取这样***破坏性的新革手段。
然而历史的车轮无法逆转，在如今的技术世界中、企业变革的步伐正逐渐加快，我们也不得不对已经效力多年的IT流程作出调整。为了追求效率并降低运营成本，我们需要直面否定以往三十年经验所带来的阵痛与阻力。过去总是美好的，但IT部门永远不可能重现当初那段用三十年时间完成同一项任务的轻松时光——时至今日，摆在面前的是更严苛、但又丝毫无法妥协的要求，除了接受别无它法。
英文原文：How DevOps Can Accelerate the Cloud Application Lifecycle
