持续集成良好实践 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. 参见老马持续集成认证博客

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券