持续集成良好实践 v0.2

团队在实践“持续部署”和“持续交付”之前，要先做好“持续集成”。

本文标题之所以没有使用“最佳实践”，而是使用了“良好实践”，是因为下面每个实践在各个背景不同的团队落地时，都有可改进的空间。

持续集成规则

持续集成认证测试[1]

1. 每位正在编写代码的程序员，每天至少一次将所写代码合并到团队代码主干。
2. 每次团队代码主干上的代码合并，都能自动触发部署流水线的构建和自动化测试。
3. 如果上述自动触发的构建和测试运行失败，则团队能在此之后，既不合并代码到主干（除非是修复代码），也不从主干获取代码，且能10分钟内修复（提交新的修复代码或回滚）部署流水线。

如果你的团队能同时做到上述3点，那么就可以给自己团队颁发一个“持续集成”证书，挂在墙上最显眼的位置。

7步提交法

7步提交法

• 前提：团队代码主干对应一条部署流水线，且每次主干上的代码合并，都能自动触发部署流水线的构建和自动化测试，同时团队能随时看到部署流水线的健康状况。

1. 编写新代码前获取最新代码：开发人员在从主干获取最新代码之前，先在本地运行自动化测试并通过；开发人员检查部署流水线健康状况。如果发现流水线是红的（有问题），则立即参与修复或回滚流水线，直到流水线变绿；开发人员从主干上获取最新代码到本地，并解决相应的冲突；开发人员再次在本地运行自动化测试，并确保测试通过。
2. 编写新代码：开发人员在本地为新用户故事或缺陷修复编写新代码。
3. 本地构建：开发人员频繁在本地运行自动化测试，并确保测试通过。
4. 解决冲突前再次获取最新代码（因为在做第2步编写新代码时，其他人有可能已经往主干上提交了代码）：开发人员检查部署流水线健康状况。如果发现流水线是红的（有问题），则立即参与修复或回滚流水线，直到流水线变绿；开发人员从主干上获取最新代码到本地，并解决相应的冲突；开发人员再次在本地运行自动化测试，并确保测试通过。
5. 解决冲突后获取代码（因为在做第4步解决冲突时，其他人有可能已经往主干上提交了代码）：开发人员在确保部署流水线健康的情况下，从主干获取代码，解决冲突，在本地运行自动化测试，直到主干上没有最新代码，且本地自动化测试运行通过。
6. 提交代码到主干：开发人员提交代码到主干，部署流水线的构建和测试自动触发。
7. 提交后确保流水线健康：开发人员观察部署流水线的健康状态，如果发现流水线是红的（有问题），则立即修复或回滚流水线（确保10分钟内修复），直到流水线变绿，才能下班。

构建与部署

包传递

在部署流水线上，代码只构建一次，然后将这次构建后的同一个二进制包，分别部署到SIT、UAT、准生产和生产环境，依次进行不同种类的测试。

代码与配置分离

将每个测试和生产环境的配置参数，与代码分离，并存储在版本控制系统中。通过测试和生产环境的环境变量来保存相应环境的配置参数。

部署方式一致

使用同样的方式，将构建出的二进制包，依次部署到SIT、UAT、准生产和生产环境，以便测试部署方式本身。

冒烟测试

二进制包部署到SIT、UAT、准生产和生产环境后，都要进行冒烟测试。

各环境尽量一致

SIT、UAT、准生产和生产环境的系统及其配置要尽量一致。

构建包容易获得

团队任何成员都能容易地获取最新构建的二进制包进行测试。

自动部署

部署流水线能自动把最新构建的二进制包部署到SIT等测试环境。

部署流水线可视化

团队任何成员都能容易地看到部署流水线的健康状态，比如使用显示屏或警报灯。

代码静态扫描

持续集成流水线每次构建，能使用诸如SonarQube工具来扫描代码内在质量，并反馈给团队，偿还技术债。

版本控制一切代码

团队的所有代码，包括测试代码、构建脚本、部署脚本都统一管理在版本控制库中，并通过持续集成流水线持续得到更新和验证。

1. 参见老马持续集成认证博客 ↩