持续集成：集成点的顿悟在于它们控制着产品开发。它们是改进系统的杠杆点。当集成点的时机出现失误时，项目就会陷入困境。

集成点的顿悟在于它们控制着产品开发。它们是改进系统的杠杆点。当集成点的时机出现失误时，项目就会陷入困境。 ——Dantar Oosterwal，《精益机器》

持续集成

持续集成 （CI） 是持续交付管道的一个方面，在该管道中开发、测试、集成和验证新功能，以准备部署和发布。

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

详情

持续集成是每个敏捷发布序列（ART）的关键技术实践。它提高了质量，降低了风险，并建立了快速、可靠和可持续的发展步伐。

通过持续集成，系统始终运行，这意味着即使在开发过程中，它也是可部署的。CI 最容易应用于软件解决方案，在这些解决方案中，经过测试的小型垂直线程可以独立交付价值。在更大的多平台软件系统中，挑战更加艰巨。每个平台都有技术结构，需要持续集成以验证新功能。当系统由供应商提供的软件、硬件、组件和服务组成时，CI 就更加复杂了。但事实是，频繁地将功能集成和测试在一起是充分验证解决方案的唯一实用方法。

因此，团队需要一种平衡的方法，使他们能够建立质量并快速获得有关其集成工作的反馈。对于纯基于软件的解决方案，使用现代工具相对容易实现持续集成。对于具有硬件和软件的更复杂的系统，需要一种持续集成方法（请参阅企业解决方案交付一文），以平衡频率、集成范围和测试之间的经济权衡。

持续集成的四项活动

如图 2 所示，SAFe 描述了与持续集成相关的四个活动：

1. 开发描述了实现故事并将代码和组件提交到版本控制所需的实践

2. 构建 描述了创建可部署二进制文件并将开发分支合并到主干中所需的技术

3. 端到端测试描述了验证解决方案所需的实践

4. 步骤介绍在生产之前在暂存环境中托管和验证解决方案所需的步骤

开发

开发解决方案是指通过根据需要细化ART待办事项列表中的功能来实现故事，然后对工作产品进行编码、测试并将其提交到源代码管理系统中。此活动中的测试往往侧重于单元级和故事级测试，并且通常需要测试替代（请参阅测试驱动开发）来复制不易获得或不易测试的其他组件或子系统。

有几种做法与开发解决方案相关联：

将功能分解为故事 – 这可以通过小批量和平滑集成实现持续交付，包括创建用户故事地图以确保工作流满足客户需求。

行为驱动开发 （BDD） – BDD 是产品所有者和团队用来更好地理解需求和提高质量的过程，通常是在编写代码之前创建验收标准和自动执行测试。BDD 与 TDD 一起工作，此处对此进行了描述。

测试驱动开发 （TDD） – TDD 涉及首先编写单元测试，然后构建通过测试所需的最少代码。这种测试技术可以带来更好的设计、更高的质量和更高的生产率。TDD 与 BDD 一起工作，此处将进一步描述。

版本控制 – 有效的版本控制使团队能够快速从问题中恢复并提高质量，确保正确组件的集成。 在版本控制下聚合资产是持续集成成熟度的主要指标。

内置质量 – 内置质量规定了围绕流程、架构和设计质量、代码质量、系统质量和发布质量的实践。

应用程序遥测 – 应用程序遥测是获取应用程序数据，然后使用应用程序数据来帮助确定相关假设结果的主要机制。

威胁建模 – 除了在持续探索（架构师步骤）中完成的威胁建模外，系统设计还应识别团队可能在新功能中引入的漏洞。

构建

在构建阶段，团队会不断集成新代码。自动执行生成和测试工具以在代码提交时运行是集成的最佳方式之一。通过与尚未通过以及未通过的自动化测试是进步的客观指标。自动化代码构建使团队能够在问题影响系统中更重要的部分之前快速解决问题。解决损坏的构建应该是最高优先级。“门控提交”确保软件在签入主代码库或主干之前已通过门控（例如，单元测试、性能测试、没有已知缺陷等）。通过测试的代码会自动集成，从而消除了管理多个源代码分支的复杂性。基于 Trunk 的开发有助于确保代码可以可靠地按需发布，而不会造成代价高昂的代码冻结。

五种做法可以帮助构建高质量的解决方案：

持续代码集成 – 代码提交应自动触发更改的编译和测试。理想情况下，这在每次提交时都会发生，并且应该每天发生几次。

构建和测试自动化 – 自动化编译过程包括单元级和故事级测试，以验证更改，通常需要测试加倍才能实现快速构建和复制其他系统。

基于主干的开发 – 团队应该快速集成代码，至少每天集成一次代码，或者最好在提交时集成代码，并且所有团队都应该在单个主干上工作，避免长期存在的分支。

门控提交 – 提交到主干是有风险的，因为中断的更改可能会影响许多团队。因此，只有通过生成和测试过程验证的修改才会合并到此分支中。

应用程序安全 – 代码分析工具检查代码和第三方包中是否存在已知漏洞。

端到端测试解决方案

虽然很关键，但自动化的本地故事和组件测试是不够的。需要系统级集成和测试才能彻底测试功能。图 3 说明了系统团队如何帮助经常整合所有团队在 ART 上的工作，并提供一些客观的进展证据。

系统级测试经常在迭代期间进行，最好是在每次提交之后。但是，无论在何种情况下，这种全系统集成都必须在每次迭代中至少完成一次。否则，较晚发现早期迭代中的缺陷和问题会导致大量返工和延迟。

六种做法可以帮助改进端到端系统测试：

测试和生产环境一致性 – 环境一致性可确保测试执行解决方案，就像它在实时用户面前的行为一样，并降低缺陷逃逸到生产环境中的可能性。

测试自动化 – 自动化测试应包括各种测试，例如功能测试、集成测试、回归测试等。敏捷测试一文详细介绍了哪些内容可以自动化，哪些内容应该自动化。

测试数据管理 – 为了创造稳定性，测试必须保持一致和真实，尽可能多地复制生产，并在源代码控制下进行。

服务虚拟化 – 不同类型的测试需要不同的环境。服务虚拟化使团队能够模拟生产环境，而无需与创建和管理物理基础架构相关的成本和工作量。

测试非功能性需求 （NFR） – 系统属性（如安全性、可靠性、性能、可伸缩性和可用性）至关重要，需要测试。

与供应商的持续整合 – 供应商带来了独特的贡献，可以缩短交货时间并改善价值交付，这需要持续整合。它有助于采用共享的集成节奏并建立客观的评估里程碑。

步骤

最后，ART 必须根据以下做法在暂存中验证整个解决方案：

维护暂存环境 – 与生产环境非常相似的暂存环境为此类验证提供了场所。

蓝/绿部署 – 蓝/绿部署模式涉及两个环境：实时（生产）和空闲（暂存）。更改持续流向空闲、暂存，并为生产部署做好准备。准备就绪后，配置更改将切换两个环境。闲置变为活动，而旧的活动变为新的闲置。这种方法可实现持续交付、零停机部署和快速故障恢复。

系统演示 – 这是利益相关者评估解决方案是否适合生产部署的地方。

实现持续整合的文化

持续集成大型复杂系统是一个耗时的过程。以下部分提供了一些建议，以建立蓬勃发展的CI文化和实践。

经常集成 – 团队集成的频率越高，他们发现问题的速度就越快。而且越难做，他们就越需要这样做。这种做法消除了障碍，并在此过程中增加了自动化，从而加快了学习周期并减少了返工。

使集成结果可见 – 当集成过程中断时，每个人都应该知道它失败的原因。修复后，创建新测试应更早地检测到问题并防止其再次发生。

修复失败的集成是重中之重 – 继续解决集成失败的团队无法达到与构建生产就绪系统相关的价值观和文化。团队经常使用闪光灯或其他通知，提请人们注意损坏的构建，并建立可见的指示器，显示系统保持损坏的时间百分比。

建立共享的节奏 – 当所有团队都遵循相同的一致节奏时，更容易访问集成点。假设团队无法在迭代中进行完全集成。在这种情况下，他们可以在短期内权衡可能的情况，同时不断改进他们的技术和基础设施，以实现这一目标。

开发和维护适当的基础架构 – 有效的持续集成取决于测试和暂存环境的可用性。当然，基础设施是一项投资。但是，精益敏捷领导者着眼于长远，今天就进行必要的投资，以提高未来马拉松的速度。

应用支持性软件工程实践 – 在设计系统时考虑到这些问题时，更容易实现持续集成。测试优先的可测试性开发和规划需要更多的模块化解决方案和关注点分离，以及使用主要接口和物理测试点。

CI 文化的另一个重要方面是确保价值在管道中的快速流动。有关使价值不间断地流动的更多信息，请参阅 ART Flow 文章（原则 #6）。

实现与 DevOps 的持续集成

持续集成涉及关键的“开发”活动，这些活动最初激发了DevOps中的“开发人员”。这些活动侧重于解决方案开发和通过预生产环境的管道流。在价值流的这一部分应用DevOps思维、实践和工具，可以实现快速开发、频繁的代码集成以及内置的质量和合规性。

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

例如，在持续交付管道中构建解决方案需要跨多个 DevOps 域。将代码签入版本控制会触发部署管道调用自动合并、质量和安全检查，然后应用存储为代码的配置来构建可交付的全栈二进制文件。使用 DevOps，此过程通常会快速将源代码转换为经过测试的可部署解决方案。

所有四个持续集成活动都由 DevOps 启用，尽管技术实践和工具的组合不同。有关 DevOps 及其如何实现持续交付管道的更详细指南，请参阅 DevOps 系列文章。