持续部署：为了跟上客户需求，需要创建部署管道。您需要在版本控制中获取所有内容。您需要自动执行整个环境创建过程。你需要一个部署管道，可以在其中创建测试和生产环境，然后完全按需将代码部署到其中。

为了跟上客户需求，需要创建部署管道。您需要在版本控制中获取所有内容。您需要自动执行整个环境创建过程。你需要一个部署管道，可以在其中创建测试和生产环境，然后完全按需将代码部署到其中。 ——Erik to Grasshopper, The Phoenix Project

持续部署

持续部署 （CD） 是持续交付管道的一个方面，它可自动将新功能从暂存环境迁移到生产环境，并在生产环境中发布。

CD 是持续探索 （CE）、持续集成 （CI）、持续部署 （CD） 和按需发布四部分的持续交付管道 （CDP） 中的第三个方面（图 1）。

功能必须在生产中可用并经过验证，然后业务才需要它们来支持按需发布。因此，最好将部署过程与发布过程分开，使更改能够在不影响当前系统行为的情况下转移到生产环境。持续部署允许团队持续对生产环境的小型增量更改。

持续部署的能力对于按需发布至关重要。反过来，它允许敏捷发布列车 （ART） 在最短的可持续交付周期内以尽可能高的价值响应市场机会，允许客户在准备就绪时使用新功能。

详情

传统的开发实践将部署和发布视为同一活动。在此模型中，部署到生产环境的更改可立即提供给用户。但是，持续部署将部署和发布过程分开。这种做法通过以下方式培养设计思维和快速价值流动：

针对特定客户定位功能 – 使组织能够以具有特定功能的客户为目标，从而允许组织在将功能部署到所有客户之前评估更改的影响。

促进实验，例如 A/B 测试 – 设计思维实践（如 A/B 测试）需要能够向不同的目标用户展示不同的功能，收集有助于创建最佳用户体验的反馈。

促进小批量 – 自动化 CDP（例如，测试、构建、部署）使小批量部署在经济上可行。

根据业务需求发布 – 当部署过程复杂且容易出错时，ART 的发布频率往往较低。投资于自动化和持续改进流程的组织可以更快、更低风险地发布产品，从而大大提高业务敏捷性。例如，可以在营销活动之前在生产环境中部署发布，使组织在最大限度地实现价值交付的各个方面具有更大的灵活性。

为了实现这些功能，ARTs专注于通过自动化连续部署的所有方面来降低事务成本和将更改转移到生产的风险。确保部署过程是可重复的、可预测的活动，不会发生重大事件，有助于团队实现持续部署。此外，改进部署以使价值不间断地情况下流动（原则 #6） 对于实现业务敏捷性至关重要。有关详细信息，请参阅 ART Flow 一文。

持续部署的四项活动

SAFe 描述了持续部署的四个活动，如图 2 所示。

部署 – 将解决方案部署到生产环境所需的做法

验证 – 在将解决方案更改发布给客户之前，确保解决方案更改在生产中按预期运行所需的做法

监控 – 监控和报告生产中可能出现的任何问题的做法

响应 – 快速解决部署期间可能发生的任何问题的做法

部署

部署是将更改迁移到生产环境中。在 CDP 中，部署更改是连续完成的。部分功能可以在生产中增量实现。

假设用户故事地图有 27 个故事来实现新工作流。传统的遗留做法可能会导致将所有 27 个故事部署在一个大批量中。相反，单个故事可以在“黑暗模式”下部署，并具有持续部署和功能切换。当 ART 部署了完整的功能集后，企业可以选择何时向用户发布这些功能。

理想情况下，部署管道会在成功构建、集成和验证后自动触发部署过程。这种方法使工作流成为从代码提交到生产部署的全自动一键式流程。高度复杂的企业可以随时可靠地部署，即使在高峰期也是如此。此方法消除了在周末、晚上或其他非工作时间进行部署的需要。

有几种做法有助于提高部署能力：

黑暗发布 – 能够将新功能部署到生产环境，而无需将其发布给最终用户

功能切换 – 一种通过在代码中实现切换来促进黑暗发布的技术，该技术可以在新旧功能之间切换

部署自动化 – 能够自动部署从暂存到生产的经过测试的解决方案

选择性部署 – 能够根据地理位置、细分市场等标准部署到特定生产环境，而不是其他环境

自助部署 – 当部分实现自动部署时，自助服务允许单个命令将解决方案从暂存移动到生产环境

版本控制 – 在版本控制下维护环境可实现快速部署和恢复

蓝/绿部署 – 一种允许在暂存环境和生产环境之间按需切换的技术

验证

在向最终用户发布之前，必须验证部署的功能完整性和可靠性。当紧密耦合时，这两个过程几乎同时发生，因此恢复决策成为首要问题。然而当它们分开时，在批准发布新功能之前，可以在生产环境中广泛测试新功能。迁移到生产环境后，解决方案将进行最后一轮测试。通常，这需要冒烟测试、轻度用户验收测试以及压力和性能测试，这些测试必须在生产环境中进行。此验证提供必要的健全性检查，用于测试解决方案在其实际生产解决方案上下文中的行为。

持续集成合理地确保解决方案在生产中按预期运行;然而，意外确实会发生。当验证发现严重缺陷时，必须快速回滚或修复部署，以防止它们损害生产环境或中断业务流。

四种做法有助于在部署后推动验证：

生产测试 – 使用功能切换或“黑暗发布”在生产中测试解决方案

测试自动化 – 自动化测试并快速、重复地运行测试的能力

测试数据管理 – 在版本控制中管理测试数据，以确保自动化测试的一致性

测试非功能性需求 （NFR） – 团队还测试系统属性，例如安全性、可靠性、性能、可扩展性和可用性，以确保 NFR 符合质量标准

监控

验证已部署的功能在进入生产环境的过程中是否未中断是一项必不可少的预发布质量检查。但是，团队还必须确保他们能够衡量功能在其生命周期内的性能和价值。推动这一关键反馈循环的见解主要来自强大的监控功能，这些功能必须在发布之前到位。

有效的监控需要对通过CDP部署的所有功能启用全栈遥测。通过此遥测技术，团队可以在生产中快速准确地验证系统性能、最终用户行为、事件和业务价值。收集的数据提供对每个功能的跟踪和监控，提高对所交付业务价值的分析的保真度，并提高对生产问题的响应能力。

虽然团队在发布之前无法收集某些业务价值指标，但他们需要知道如何在发布决策之前获得这些指标。一些有助于支持这一点的做法包括：

全栈遥测 – 能够监控系统覆盖的整个堆栈中的问题

可视化显示 – 显示自动测量的工具

联合监视 – 在解决方案中跨应用程序进行整合监视，从而创建问题和性能的整体视图

Measure & Grow 一文提供了一些关于监视所需的指标类型的指导。

响应

响应不可预见的生产问题并从中恢复的能力对于支持持续部署和简化 CDP 至关重要。原因很明显：

生产问题直接影响客户和最终用户，因此当问题发生时，已部署解决方案的价值会迅速下降。

生产问题会导致返工 - 修复、补丁、重新开发、重新测试、重新部署等。这扰乱了通过管道的正常价值流动。

由于生产问题会损害交付效率并降低价值，因此团队需要能够主动检测问题并快速恢复。根据平均恢复时间（MTTR）衡量，快速恢复是DevOps成熟度高的最可靠领先指标之一。恢复也是 SAFe 的 CALMR DevOps 方法的五个要素之一。

响应和恢复的目标是在潜在问题变成事件之前识别它们，并防止它们影响业务运营。此功能需要在最终用户发现问题之前在内部检测问题，快速确定根本原因，并通过经过精心演练的程序恢复服务。相反，直接对生产系统进行仓促的、被动的更改（“只是为了保持正常”）会导致环境之间的源代码和配置差异、未经验证的更改和长期风险。

有几种做法支持响应生产问题并从中恢复的能力：

主动检测 – 一种在解决方案中主动创建故障的技术，以便在潜在问题和情况发生之前识别它们。例如，由 Netflix 开发的 Chaos Monkey 是一个开源工具，它会在生产中随机终止实例，以确保工程师实现他们的服务以抵御实例故障。

跨团队协作 – 跨价值流合作的心态，以识别和解决出现的问题

会话回放 – 能够回放最终用户会话以研究事件并识别问题

回滚和前向修复 – 既可以快速回滚解决方案到以前的环境，也可以通过管道快速修复问题，而无需回滚

不可变的基础结构 – 此概念是指在部署后从不修改服务器或虚拟机 （VM）。相反，如果需要更新某些内容，则从具有适当更改的映像构建新服务器。

版本控制 – 环境应在版本控制下维护，以便快速回滚

在团队证明功能已成功部署到生产环境中，并具有必要的监视和恢复功能来跟踪和管理持续价值后，他们已经完成了 CDP的持续部署阶段。反过来，这使企业能够在必要时发布。

使用 DevOps 实现持续部署

持续部署涉及经常与DevOps中的“Ops”相关的关键操作活动。他们专注于将解决方案部署到生产环境，验证其功能完整性，并确保有效的监视和发布后支持。

图 3 说明了 SAFe 的 CALMR DevOps（中心）和多个实践域（内环）方法支持持续部署。这四项活动中的每一项（绿色）都是协作成果，它利用了来自多个学科的 DevOps 专业知识，以最大限度地提高交付速度和质量。

例如，在CDP中部署解决方案涉及使用以下工具：自动化生产基础架构的资源调配、部署解决方案二进制文件以选择目标、验证生产功能、捕获运行时遥测，以及主动发出问题警报。DevOps 实践和工具简化了这些功能，允许在几分钟内部署解决方案并为按需发布做好充分准备。

所有四个持续部署活动都由 DevOps 实现，尽管有不同得技术实践和工具组合。请参阅 DevOps 系列文章，了解有关 DevOps 及其如何促进 CDP 的更多指导。