定义

持续集成是一种软件开发实践，团队成员频繁地将工作成果集成在一起，每次提交后，自动触发运行一次包含自动化验证集的构建任务，以便能尽早发现集成问题。其具体流程如下：

• 开发人员将代码提交到代码仓库；
• 持续集成服务按一定的时间间隔对代码仓库进行轮询，发现有代码变更；
• 持续集成服务器自动将最新的代码检出到已准备好的专用服务器上；
• 在专用服务器上运行由持续集成服务器制定的构建脚本或命令，对最新的代码进行检查，比如静态扫描、编译打包、运行单元测试、部署并运行功能测试等；
• 运行结束后，将验证结果反馈给开发团队。

持续集成这一实践体现了快速验证环的基本工作原则，即“质量内建，快速反馈”。开发人员每完成一项开发任务后，必须通过运行一系列的自动化质量检查，验证其所写代码的质量是否达到了团队能接受的软件质量标准。

六步提交法

持续集成实践要求团队成员拥有较高的纪律性，团队中任何一个改动代码的人都必须遵循下面的六个步骤：

1. 检出最近成功的代码：工程师在开始工作时，要将最近一次构建验证成功的代码版本从主干分支检出到自己的开发工作区上。
2. 修改代码：在个人工作区对代码进行修改。
3. 第一次个人构建：执行自动化验证集，对自己工作区的新代码执行第一次个人构建（被称为本地构建），用于验证自己修改的代码质量是否达标。
4. 第二次个人构建：从“检出代码”到“第一次个人构建”期间，可能有其他成员在主干分支提交了代码，并通过了持续集成的质量验证。此时，需要将别人合入的新代码与自己本地改的代码进行合并，再执行一次质量验证，确保自己的代码与其他人的代码都没有问题。
5. 提交代码到团队主干：第二次个人构建成功之后，就可以提交代码。
6. 提交构建：持续集成服务器发现了代码变更，立即开始执行提交构建，运行自动化质量验证；如果构建失败，则应该立即着手修复，并通知其他成员，禁止再向团队开发主干提交代码，并且不要检出这个版本。
   六步提交法

六步提交法的关键点

三次验证的作用

六步提交法中的3，4和6都是质量验证活动，并且三次验证都执行相同的命令和脚本，那为什么要执行三次呢？这三次的作用不一样。

• 第一次个人构建：验证开发者自己修改过的代码是否正确；
• 第二次个人构建：确保其他人的代码与自己的代码合并后，两部分的代码质量都没有问题；
• 提交构建：在一个干净且受控环境中执行，确保开发人员的本次提交是完整且无质量问题的，没有遗漏。

个人验证一定要做两次吗

两次质量验证的目的不一样，最好是完成两次验证，比较容易定位问题；如果一个自信爆棚的工程师认为只要进行一次个人构建，应该保留第二次个人验证，如此可以保证“提交构建”这个阶段失败的可能性最小。

如何确保在提交前执行个人构建

一种方式是由持续集成平台捕获提交时间，在代码合并到主干之前，强制进行第二次个人验证；也可以通过跟团队成员口头约定的方式。

每次构建应该包含哪些质量验证内容

不仅要包括自动化单位测试，还需要运行更丰富的质量验证集合，包括代码动静态扫描、代码规范检查、构建验证测试等。

• 构建结束后生成的二进制包是否包含了正确的内容，例如配置文件的完整性；
• 构建结果是否能够正确安装并正常启动运行起来；
• 启动后最基本的功能是否可以使用，比如用户登录。

规范扫描出数量巨大的已存问题，如何处理

• 减少规范，关注重点：大部分规范检查工具都会将问题分为多种类型，比如严重、重要或警告。团队应该讨论，提取最重要的代码规范，早起只关注严重类型的问题，以后再逐步增加代码规则；
• 执行“童子军营地”原则：如果遗留代码量比较大，并且在生产环境已经运行很久，且最近不会修改它们，可以暂时不修改它们。即使不能立即将问题全部清理，也要保证每次提交代码时，都不让问题的数量继续增长。

童子军营地原则：美国社会针对未成年人的一种教育实践制度，加入童子军的小朋友都要学习并遵守的一些规则。其中一条就是离开宿营地前进行清扫活动的原则，确保营地和你使用之前一样干净，能再干净一点就更好。

自查表

如何评估团队是否达到了持续集成的最佳状态？如下六个方面自检：

1. 主干开发，频繁提交：在主干分支上提交代码，或者其他分支的生命周期不超过3天，每个团队成员频繁向仓库提交代码；
2. 每次提交应该是一个完整的任务：每次提交的内容应该是有意义，而不是仅仅为了达成提交频率而提交无意义的代码；
3. 让提交构建在10分钟内完成：每次构建验证的时间越短越好，运行时间太长无疑会降低中质量反馈的速度；构建验证的时间越长，问题修复时的切换成本就越高；
4. 一旦失败停止代码提交和检出：一旦构建失败之后，团队应该禁止其他成员提交新的代码，也不允许其他人检出该代码，遵循“丰田式生产管理系统”的“立即暂停原则”；
5. 要求10分钟内修复问题，否则回退代码：如果修复时间过长且未恢复，会另整个团队未提交的代码数量累计过多，潜在的集成问题可能会更多，提交构建失败的概率更大，修复时间更长，这是一个恶性循环。
6. 自动化构建验证通过后，对软件质量有比较大的信心：持续集成的真正目的是得到快速有效的质量反馈，即只要自动化构建成功，对软件质量就有信心，不能因为测试用例失败了就删除该测试用例。

速度与质量的权衡

为了能够更加全面地反馈软件质量，可能会增加更多的自动化功能测试用例，而随着测试用例的不断增加，会导致自动化测试运行时间太长，无法再10分钟内反馈执行结果，那么，该如何处理呢？

分级构建

引入“次级构建”的方法，团队将自动化验证分成两部分，如下：

• 提交构建：包括运行速度快、反馈质量高的测试用例；
• 次级构建：包括执行较慢，不经常失败的测试用例，在“提交构建”验证成功之后再触发执行。
  分级构建
  开发人员只要提交构建验证成功之后，即可开展其他工作任务，而不需要等待次级构建验证完成返回结果。但是，一旦次级构建执行失败，应该立即发出通知，相对应的开发人员需要立即进行修复，并通知所有人在问题修复之前停止提交和检出代码。

多次提交一起执行次级构建

在资源受限并且次级构建执行时间长的情况下，如何提交验证的效率显得非常重要。在多人一起提交的情况下，容易出现资源的浪费情况，如图，Sara提交触发的次级构建执行失败，那么Bob和Martin的次级构建一定会失败。

多次提交一起执行次级构建

为了提高构建的效率，可以将Bob,Martin和David的次级构建一起执行，如果Sara的次级构建执行成功了，但是Bob,Martin和David的次级构建失败了，可以手动触发Bob和Martin的次级构建来定位具体出错的次级构建。

充分使用云平台

云计算基础设施的发展为持续交付提供了更强大的资源支持和便利性，在持续集成的过程中，充分利用云平台的资源来提升构建的效率是非常重要的。

在团队中实施持续集成实践

快速建立团队的持续集成实践

快速建立团队的持续集成实践

构建持续集成的5个步骤：

• 构建脚本化，搭建持续集成框架：完成一款持续交付工具的安装和配置，并建立任务可以检测代码仓库的变化，并可以实现代码的编译、构建和打包工作。
• 向构建中添加已有的自动化验证集合：向构建中添加自动化测试用例和代码规范扫描。
• 选择利于持续集成的分支策略：每个分支建立对应的持续集成环境，分支不宜太多，不利于团队持续集成的效果；根据团队的实际情况选择有利于持续集成的分支策略，并建立相对应的自动化部署流水线。
• 建立六步提交法：对团队成员进行培训，指导团队成员按照持续集成六步提交法来进行日常的开发工作。
• 持续优化：持续的为整个持续集成的流程进行优化，优化的方面包括编译打包时间、代码分支策略、自动化测试用例的分层分级、测试环境的准备、编译规范的扫描和数据报告的生成等方面。
• 工程师改变习惯，并提升技能：持续集成是一个积极的团队协作实践，要求工程师主动提前集成，而不是推迟集成，这与人们的“推迟风险”的心理相违背，需要工程师改变工作习惯，并投入一些时间来学习相关的方法与技巧。

分支策略与部署流水线

团队间的持续集成方法与团队所采纳的代码分支策略密切有关，每创建一条分支，都应该立即创建与其对应的部署流水线，直至该分支的生命周期结束。

• 主干开发，主干发布：只需要对主干分支做继续集成，只需要一个持续集成服务，关注主干分支的代码变更即可。
• 主干开发，分支发布：团队每当准备发布时应该创建新的发布分支，并为这个发布分支创建对应的部署流水线。
• 分支开发，主干发布：需要为每个开发分支架设一条对应的部署流水线，并且每当有分支向主干合入代码时，立即出发主干对应的部署流水线；当分支上的代码提交不再活跃，或者分支直接被删除后，其对应的部署流水线也可以被删除。
  分支开发，主干发布
• 多组件集成策略：软件产品由多个服务或组件构成，并且每个服务有独立的代码仓库，每个仓库可能都有自己不同的分支策略。此时，根据前面讲的3中不同策略，为每个独立代码仓库建立各自的部署流水线，再创建一条集成用的部署流水线，该流水线并不轮询任何代码仓库，而是由上游的多个部署流水线触发。一旦上游的部署流水线成功完成，这条负责集成的流水线就应该对获取上游流水线生产的软件包进行集成构建验证。
  多组件集成策略