大多数IT或其他领域的项目，都依靠大规模变更完成交付。团队的目标是在最大程度满足需求的同时，在6、12、18个月甚至是更长的时间内完成项目交付。

而现在项目最终交付需要在几个月内完成。为期18个月的项目解决的是18个月之前的旧有问题，等到项目交付时，各方对该问题的认知很可能已经发生了变化。18个月的实施周期造成了在最新的交付版本中要附加许多升级内容，这无疑增加了变更管理的复杂度和成本，对于最终用户和工作人员来说都是不小的负担。

在IT领域，满足最新的动态的业务需要已经成为此类项目实施过程中的共识，因此必须做出改变。

许多IT公司正在考虑实施连续交付，来取代当前遵照严格计划执行的整体瀑布方法所交付的单一版本的情况。有了连续交付，IT团队将设计“足够好”的系统（将系统的版本考虑为V0.8而不是V8。译者注：此处版本的标识意为持续改进）能够满足全部的主干需求。秉承着真实和宽容的态度，最终用户测试不同的版本，并针对哪些功能好用、哪些功能不好用、哪些功能缺失以及哪些功能可以做得更好等提供持续的反馈。

项目团队会跟踪反馈过程持续修正和改进，越多的用户参与系统测试，系统就能因此变得更加完善。一旦部署到实际的运行环境中，系统不会根据几个月之前所编写的一系列需求文档，也不会根据开发人员的心情选取那些他们感兴趣并容易实现的内容去改进，而是能够根据实际用户的持续需求增加新的功能特性。

调整为持续交付主要需要创造出更加敏捷的交付过程。IT公司能够对已经存在的系统持续进行新功能的更新，用尽可能短的时间处理突发问题。持续交付也允许公司像在个人平板电脑或智能手机上管理消费端应用程序那样管理最终用户，经常性的小修小改的更新并不需要重新培训用户。

大规模的变更会持续存在并可能引发问题。主要的变化在于没有正式的培训，用户的操作习惯被重置，他们希望了解如何继续完成自己的工作任务。但这也将减少大规模变更的数量，减少对于变更管理的需求。

最佳适配

持续交付对于那些具有开放思维的公司最为合适，即认同IT和业务可以借助投资实现，并且接受初次实施可能不完美这一观点。在快速多变环境中的公司，例如在高科技领域、零售和消费品市场以及多媒体行业的公司是实现持续交付模式的理想候选企业。

零售业网站Etsy已经应用持续交付有6年左右。基于云端的信息存储、协作和交付平台Box，也在约3年前接受了持续交付的理念，Adobe公司也在其创立伊始就在Creative Cloud平台上应用了持续交付的方法。

即使是在外部环境较为固定或高度传统的行业，例如金融、制药和重工业，也可以应用持续交付理念。持续交付能够很好地处理传统瀑布方法实施的大项目中组件方面的内容更新。然而，这些行业的公司可能不会全面应用持续交付和DevOps技术，只是允许代码在开发环境和运行环境之间采取更加自由的流动方式。

最初版本一旦上线，信息反馈的途径就变得至关重要。用户们都提出了哪些反馈？他们向求助栏目上报了哪些主要问题？项目组必须鼓励这些反馈，并合理收集和利用这些信息。

项目团队会从具有高优先级的问题列表中选择哪些对于业务流程影响最为深刻的问题进行优先处理。例如，用户并不喜欢某项工作的接口设计，或认为其在业务逻辑上存在重大纰漏。随着用户对最初版本的适应，也会出现对新增功能的要求。确保开发者能够对被证明是用户痛点的内容保持快速响应和持续改进。

在很多案例中，都存在着繁重的重复劳动的情况。例如，很多功能在软件中是作为服务提供的。在内置软件中创建一项具有相同作用的功能也许并不是公司需要和要求的。定制化的功能需要IT运维团队管理跟踪、打补丁和执行升级，没有一项是免费的。标准化的、现成的功能的成本和应用效果都是已知的，相比于公司想要单独定制开发、测试和上线的功能，更容易快速实现。

在持续交付中不要设置检查点。当变更已经就绪，某些团队会停下来，直到某个人决定这些变更可以更新交付到产品后才会行动。这样做是错的，持续交付的核心思想是尽可能快速地将变更付诸实施。

要仔细理解“尽快”这一词组。持续交付并不是解决所有问题那种万能的办法。

IT公司还是要测试和记录每项变更。在部署之前，更新内容必须进行自动检查，以确保操作环境能够处理这些更改——以及IT项目组应该进行整治，尽可能使更新过程平滑完成。每项变更都应该具备回滚的功能，以防更新对产品环境造成不良影响。求助栏目的负责人还是需要了解更新的实施会对正式环境造成哪些影响。在持续交付的过程中，这些检查和平衡的过程要远比在大规模更新过程来的更加重要。

持续交付改变了人们对IT部门的认识，从公司执行力的“绊脚石”转变成为企业增强市场竞争力而提供优化IT环境的团队。

交易的工具

许多软件供应商提供帮助企业实施持续交付的工具。

Atlassian公司提供了一款全生命周期的持续交付支持系统，名为Atlassian Enterprise，该产品将Jira问题追踪、冲突协调平台和其他产品融入到同一个可管理的系统中。Electric Cloud的版本自动化工具产品——ElectricFlow和ElectricAccelerator，能够妥善管理持续交付。自动植入工作流程深处提供坚固和广范围的持续交付能力。其他在此领域的新玩家包括Xebia、Zend以及Heroku等几家公司。

对于那些富有技巧的完全开源的解决方案，使用Jenkins、Chef、Puppet、Ansible和其他工具是充分可行的。被支持的企业平台建立在由诸如Red Hat和CloudBees这样的公司所提供的这些开源工具之上。

业界更多的供应商也在开发持续集成的周边工具。CA Technologies已经对旗下的项目分类管理工具进行了改进，使其与自家的Release Automation更加能够协同一致，形成好的解决方案。IBM也提供了有用的工具，特别是当你将Bluemix应用程序开发平台和交付工具在SoftLayer的云端基础设施中进行融合的时候。BMC软件也已经升级了其IT管理和运营工具，在持续交付过程中提供软件方面的帮助。

持续交付工具的选择余地很大，定义成功选择工具的标准是找到与自己公司和IT团队需求最佳适配的工具。采用例如Atlassian、Electric Cloud或Automic等公司提供的更新、更全面的工具，能够为项目长期实施提供更好的持续性框架，这样要比绕弯或重用已存在的系统更加适合持续交付的全新过程。