团队在实践“持续部署”和“持续交付”之前,要先做好“持续集成”。
本文标题之所以没有使用“最佳实践”,而是使用了“良好实践”,是因为下面每个实践在各个背景不同的团队落地时,都有可改进的空间。
持续集成规则
持续集成认证测试[1]
- 每位正在编写代码的程序员,每天至少一次将所写代码合并到团队代码主干。
- 每次团队代码主干上的代码合并,都能自动触发部署流水线的构建和自动化测试。
- 如果上述自动触发的构建和测试运行失败,则团队能在此之后,既不合并代码到主干(除非是修复代码),也不从主干获取代码,且能10分钟内修复(提交新的修复代码或回滚)部署流水线。
如果你的团队能同时做到上述3点,那么就可以给自己团队颁发一个“持续集成”证书,挂在墙上最显眼的位置。
7步提交法
7步提交法
- 前提:团队代码主干对应一条部署流水线,且每次主干上的代码合并,都能自动触发部署流水线的构建和自动化测试,同时团队能随时看到部署流水线的健康状况。
- 编写新代码前获取最新代码:开发人员在从主干获取最新代码之前,先在本地运行自动化测试并通过;开发人员检查部署流水线健康状况。如果发现流水线是红的(有问题),则立即参与修复或回滚流水线,直到流水线变绿;开发人员从主干上获取最新代码到本地,并解决相应的冲突;开发人员再次在本地运行自动化测试,并确保测试通过。
- 编写新代码:开发人员在本地为新用户故事或缺陷修复编写新代码。
- 本地构建:开发人员频繁在本地运行自动化测试,并确保测试通过。
- 解决冲突前再次获取最新代码(因为在做第2步编写新代码时,其他人有可能已经往主干上提交了代码):开发人员检查部署流水线健康状况。如果发现流水线是红的(有问题),则立即参与修复或回滚流水线,直到流水线变绿;开发人员从主干上获取最新代码到本地,并解决相应的冲突;开发人员再次在本地运行自动化测试,并确保测试通过。
- 解决冲突后获取代码(因为在做第4步解决冲突时,其他人有可能已经往主干上提交了代码):开发人员在确保部署流水线健康的情况下,从主干获取代码,解决冲突,在本地运行自动化测试,直到主干上没有最新代码,且本地自动化测试运行通过。
- 提交代码到主干:开发人员提交代码到主干,部署流水线的构建和测试自动触发。
- 提交后确保流水线健康:开发人员观察部署流水线的健康状态,如果发现流水线是红的(有问题),则立即修复或回滚流水线(确保10分钟内修复),直到流水线变绿,才能下班。
构建与部署
包传递
在部署流水线上,代码只构建一次,然后将这次构建后的同一个二进制包,分别部署到SIT、UAT、准生产和生产环境,依次进行不同种类的测试。
代码与配置分离
将每个测试和生产环境的配置参数,与代码分离,并存储在版本控制系统中。通过测试和生产环境的环境变量来保存相应环境的配置参数。
部署方式一致
使用同样的方式,将构建出的二进制包,依次部署到SIT、UAT、准生产和生产环境,以便测试部署方式本身。
冒烟测试
二进制包部署到SIT、UAT、准生产和生产环境后,都要进行冒烟测试。
各环境尽量一致
SIT、UAT、准生产和生产环境的系统及其配置要尽量一致。
构建包容易获得
团队任何成员都能容易地获取最新构建的二进制包进行测试。
自动部署
部署流水线能自动把最新构建的二进制包部署到SIT等测试环境。
部署流水线可视化
团队任何成员都能容易地看到部署流水线的健康状态,比如使用显示屏或警报灯。
代码静态扫描
持续集成流水线每次构建,能使用诸如SonarQube工具来扫描代码内在质量,并反馈给团队,偿还技术债。
版本控制一切代码
团队的所有代码,包括测试代码、构建脚本、部署脚本都统一管理在版本控制库中,并通过持续集成流水线持续得到更新和验证。
- 参见老马持续集成认证博客 ↩