通过 7 个持续交付最佳实践，给读者一个思路，无论是建设持续交付能力，还是在进行持续交付平台的选型，都能够在业界经验的基础上走向更为正确的道路。同时，本文还引入了持续交付成熟度模型，目的是想帮助企业，把一个想象中全面而复杂的交付流程进行切分，按照环节和成熟度等级展现，将实现持续交付能力之路变得更为清晰、更可操作、有助于企业建立良好的期望和愿景，并开展切实可行的行动。
市场和业务瞬息万变，企业的 IT 部门必须面对产品上线周期不断变短的事实，也就是说，需要建立产品交付反馈圈，并让这个闭环圈的反馈速度持续提高。这个反馈圈是指，从一个新想法的产生，经过决策分析后准备付诸实施，对其立项并监控其开发，经过测试和部署，最后交付产品后得到客户反馈并继续优化这样一个完整过程。从图 1 可以看出，这个过程涉及客户以及企业的多个部门、多种角色，并且要和企业现有的多种流程、工具、方法打交道。
图 1.产品交付生命周期
业界有很多最佳实践，都可以帮助企业建立并且逐步优化自己的产品交付反馈圈，这些最佳实践涉及了软件工程的众多领域。如耳熟能详的每日构建、持续集成（CI）等，它们已经在很多企业里被广泛使用，也为企业实现持续交付打下了良好的基础。
然而，持续集成只能说是实现了反馈圈中的一个小环节，现在需要考虑更多并一步步构建完整的产品持续交付能力。因此，为了让 IT 能跟上业务思考的速度，我们需要从持续集成迈向持续交付。
持续集成更关注代码质量。持续集成是为了确保随着需求变化而变化的代码，在实现功能的同时，质量不受影响。因此，在每一次构建后会运行单元测试，保证代码级的质量。单元测试会针对每一个特定的输入去判断和观察输出的结果，而单元测试的粒度则用来平衡持续集成的质量和速度。
决定一个构建（build）是否可以交付需要更多的测试阶段。仅仅构建和单元测试能够通过，是不足以回答“是否可以交付”这个问题的。质量有很多层面，单元测试仅仅验证了一些维度，这个构建在真正能交付前不得不通过其他额外的测试阶段。
一个构建在不同测试阶段传递的过程称之为交付管道（Delivery Pipeline）。如果一个构建在任何一个测试阶段失败，它应该重新回到开发状态并继续在管道中流通。当一个构建通过了一个测试阶段，它应该被提升（promote）到下一个测试阶段。随着测试阶段的推进，一个构建可以进入到下一阶段的准入门槛也应该越来越严苛。因此，每一次提升，构建的质量都在不断提高，通过所有测试阶段的构建，才应该被提升到生产环境中。如图 2 所示。通常企业里常用的测试阶段有：单元测试--在持续集成中执行，功能测试，系统集成测试（SIT），用户验收测试（UAT）。每一个测试阶段都需要先在指定的环境中部署好构建，然后进行相应的测试。当然，企业里也会相应增加或减少特殊的测试阶段，这样就构建了自己的交付管道。
表 1 .持续交付管道（Delivery Pipeline）
持续集成 部署 构建 单元测试 功能测试 集成测试 用户验收测试 生产环境 v.1 失败 v.2 成功 失败 v.3 成功 成功 失败 v.4 成功 成功 成功 失败 v.5 成功 成功 成功 成功 已部署
交付管道的建立和自动化是持续交付的基础。如果持续集成实现了自动化而部署过程需要大量手工操作，那部署就无法跟上持续集成的节奏。部署也需要自动化，部署自动化工具可以帮助一个构建自动地在部署管道中推进，使部署本身不成为瓶颈。另外，部署自动化可以确保整个部署过程可以固化下来，在每次部署中可重复进行。这样就可以既测试待部署工件的质量，也同时验证部署流程的质量，把这种流程也作为资产管理起来。
持续交付的前车之鉴--应用交付的 7 个最佳实践
企业在构建了自己的交付管道后，关注点就需要从持续集成转向全面的持续交付，也就是将更多的关注点放到部署层面。在构建并优化持续交付能力时，企业或多或少都会面临如下的问题和风险，如：拥有大量自己开发并维护的构建和部署脚本；完全或部分的手工部署过程；难于实现部署失败时的追踪和定位等。因此，根据 Urbancode 公司（已被 IBM 收购）发布的白皮书（https://www14.software.ibm.com/webapp/iwm/web/signup.do?source=swg-rtl-sd-wp&S_PKG=ov17459），这里再次阐明应用持续交付改进的 7 个最佳实践。
实践 1：建立单一的部署来源
开发团队可能分布在各处，或者即便是一起开发也会根据业务逻辑进行团队划分。每个团队都可能有自己的一套应用部署工具和流程。小规模团队这种情况还好，而不同的流程和不同的工具对于大型团队来讲，在编排发布计划时会带来巨大的挑战和风险。
因此，在制定发布计划时，需要建立一个单一的、可信任的、实时更新的部署来源。比如说，待组装的应用组件应该放在相同的容器里进行管理，发布的流程设计应该统一风格和模式，不同环境要求的配置项或者属性信息应该统一设置和管理，等等。这样可以让接入持续交付管道的各个角色协同起来，同时提供了整个交付管道的可视性和可跟踪性，清楚的知道谁、何时、做了哪些动作。
实践 2：让令人痛苦的手工步骤自动化起来
在部署过程中的手工步骤带来了许多风险。比如说，如果这个步骤没有写的特别详细，对于新手来说就存在执行的不确定性；或者这个步骤在部署到其他环境中时遗漏了，就会导致部署失败。另外，手工步骤是难于跟踪和管理的。为了解决这个问题，尽最大可能自动化现有的部署步骤。自动化能力为完成部署步骤提供了一种安全的、被验证过的、成功率更高的手段，理想情况下，所有步骤都应该被自动化。
实践 3：管理应用内部的相互依赖关系
避免仅仅依赖开发人员口头去描述和理解应用的内部依赖关系。复杂的部署通常包含应用组件的互相依赖。如果组件 A 依赖于组件 B 的某一个具体版本，那么没有部署或者没有正确部署组件 B 将导致整个发布失败。需要将这种依赖关系通过工具管理起来，而且需要保证同时部署的组件必须一起测试过，要测试这些组件的功能和他们的兼容性。当应用在不同的测试环境移动时，必须确保这种依赖关系的顺利移动，也就是说，必须清楚的知道具有依赖关系的某个组件的某个具体版本是否被正确部署。
实践 4：让部署过程的“什么。。在哪里。。”清晰可见
不知道在某一个机器上或者某一个环境中部署了什么存在很大的风险。尤其当应用向更严格的环境中移动时风险就更大，如当应用从 UAT 环境向生产环境迁移，一个存在于 UAT 环境中的组件版本和生产环境的另一个组件不兼容，文档中并没有记录这一点，那么，这种部署就带来了极大地风险，甚至成为生产事故。另外，停止应用去跟踪和分析其部署也是非常耗时和浪费的事情。如果能对部署环节的“什么。。在哪里。。”管理起来并清晰可见，就可以确保各个环境确实成功部署了组件和组件版本。另外，跟踪应用的部署也变得非常轻松。生成工件部署清单并实时追踪分析就可以为整个应用部署带来更好的洞察力。
实践 5：让部署环节的准入条件和批准情况清晰可见
认证和审批可以确保质量。在持续交付管道中定义清晰明确的质量属性是非常重要的。只有当在某一个环境中部署的应用，符合了下一个环境的质量属性并得到审核批准后，才能将应用部署到该环境中。比如一个构建经过了 SIT 阶段，需要向 UAT 阶段移动时，理论上应该已经通过了单元测试、功能测试、性能测试、接口测试等一系列验证，并且集成测试部门经理也批准该构建可以部署在 UAT 环境中，那么，该构建的上述验证值应该为真（表示已通过验证），其部门经理批准值也为真（表示已经批准），在 UAT 测试环境的准入条件中，只有这些属性值都为真的时候，才允许部署这个构建。让这些准入条件和审核批准状态清晰可见，所有人才能知道一个应用需要什么条件才能在持续交付管道中前进。通常我们把这种质量属性称之为质量门（quality gate），它正是作为应用向下一个环境迁移的准入条件。
实践 6：在不同的环境中保持部署的一致性
不同的阶段和环境使用不同的部署流程增加了出错的概率。比如，由于生产环境使用的部署流程并没有在更早期的环境中验证过，仅在该环境下的特殊步骤就有可能出现错误。应该使用测试环境去验证会在生产环境上运行的每一个步骤。当编排和设计应用的发布流程时，应该设计成一个单一流程，它被用到整个持续交付管道中的每一个阶段中。
附加说明：
1）经常会遇到在更“高级”环境中的步骤不存在于“低级”环境中的情况。比如生产环境的一个负载平衡步骤可能就不会在开发环境中存在。这种情况下，可以使用条件分支，仅在生产环境下运行该步骤。这样，就形成了具有冗余度的统一部署流程，即便该步骤没有经过前期环境验证，一旦出错，也会立刻定位是负载平衡问题导致部署失败。
2）如果不同环境的部署过程完全不同，考虑仅设计一个“高级”环境部署过程和一个“低级”环境部署过程。避免每一个环境一个过程。为了消除环境间的差异，还可以考虑通过自动环境生成能力搭建环境，如云环境。
实践 7：发布计划简单明了
发布计划应该做到编写容易，在计划会议上讨论时就能随手制定，而且应该易于理解，让每一个持续交付管道中的角色都能知道计划是怎样的，如果发布变化产生的影响是什么。发布变更应该有便利的协作手段去审核和批准。如果发布计划难于理解，通常都会被束之高阁，这会带来一系列问题，如变更混乱，风险增加。
综上所述，如果企业正在考虑建立或优化自己的持续交付能力，非常建议能够遵循并贯彻如上的 7 个最佳实践，基于前车之鉴快速建立一套可控的、可实施的软件持续交付流程。在宏观层面，帮助企业打造完整的一套跨多个环境的标准交付流程；在微观层面，可以帮助 IT 部门清晰的了解每一次发布是否拥有确切的来源，确定的目标和可落实的流程。
确定当前状态和改进之路--企业持续交付成熟度
企业当前的持续交付流程成熟度如何？有没有哪些地方能够改进和提高？下面我们一起了解企业持续交付的成熟度模型。该成熟度模型来源于 Eric Minick 和 Jeffery Fredrick 两位专家，他们拥有多年的一手资料和实际经验，形成了一套企业可以借鉴和参考的持续交付成熟度模型。（http://www.urbancode.com/html/resources/white-papers/Enterprise_Continuous_Delivery_Maturity_Model/）
企业持续交付成熟度模型说明
不同的行业和企业，对于持续交付的理解和应用场景是不尽相同的。只能寻求到他们的共同点和主要特征。为了便于描述，我们选择了 4 个通用环节，来记录和分类企业的持续交付过程，它们分别是构建、部署、测试、报告。在每一个环节中，又根据该环节所常见的一些实践，以及企业对这些实践的应用程度，形成了 5 个成熟度等级。这 5 个等级分别是基础级、起步级、中间级、高级、领先级。同时，在每个环节中，还根据实际经验，标示出了行业普遍能力以及应该达到的目标能力。有了这样的成熟度模型，企业就可以方便的衡量出自己现在处于什么位置，离行业普遍能力有什么偏差，目标能力应该是什么，从而快速找到采取什么行动去弥补差距，实现目标。如图 3。
图 3 .持续交付成熟度模型图