持续交付之七——提交阶段

其他持续交付相关文章：《持续交付》系列文章目录

个人站点 http://ronnie.wang

第七章 提交阶段

1. 引言

提交阶段的目标

目标主要有两个

• 要么产生成功的可部署文件
• 要么快速反馈失败的原因，并阻止部署流水线之后的进程，这样可以保证错误不向后续步骤蔓延

提交阶段的开始和结束

当向版本库中进行一次提交时，提交阶段就开始了，提交阶段是部署流水线的开始

提交阶段的结果有两个

• 成功，产生可供后续测试和发布的二进制产物和可部署程序集
• 失败，得到失败报告

2. 提交阶段的原则和实践

为了建立高效的提交阶段，需要遵循下列原则和实践

2.1. 提供快速有用的反馈

如果有问题，尽早发现，尽早修改，这样解决错误所需的精力最少

2.2. 何时让构建成功

理论上将，提交阶段的失败来自于下面三种情况

• 编译错误
• 测试未通过
• 环境配置问题

但如果通过了，是真的通过了吗，是否可能有如下情况呢

• 编译警告很多
• 测试没有全部运行
• 代码质量并不高

这样还要让构建成功吗，这需要团队讨论，建立大家认可的标准，比如规定测试覆盖率，检测代码质量，控制编译警告数量等

但首要原则是，如果构建失败，交付团队要立即停止手上的工作，把问题修复

2.3. 精心对待提交阶段

对待提交阶段用到的脚本也要向对待程序的其他部分一样精心的设计和维护

这里有一些原则可供参考

• 将脚本做成模块化的
• 将那些经常使用但很少变化的与经常要修改的任务分离开来
• 将部署不同阶段用到的脚本写到不同的文件中
• 不要写出与具体环境相关的部署脚本，将具体换进配置和构建脚本分离

2.4. 让开发人员也拥有所有权

不要只让构建专家来管理构建过程，开发团队和运维团队都应参与进来，构建专家应该专注于下面的工作

• 构建过程的设计
• 构建知识的传授

2.5. 在超大项目团队中制定一个构建负责人

主要用于维护和巩固构建纪律

3. 提交阶段的结果

制品库

保存提交阶段输出结果的地方

一个候选发布版本在部署流水线中成功走向生产环境的步骤

1. 交付团队的某个人提交了一次更改
2. 持续集成服务器运行提交阶段
3. 成功结束后，二进制包，所有报告和元数据都被保存到制品库中
4. 持续集成服务器从制品库中获取提交阶段生产的二进制包，并将其部署到一个类生产测试环境中
5. 持续集成服务器使用提交阶段生成的二进制包执行验收测试
6. 成功完成后，该候选发布版本被标记为“已成功通过验收测试”
7. 测试人员拿到已通过验收测试的所有构建的列表，并通过单击一个按钮将其部署到手工测试环境中
8. 测试人员执行手工测试
9. 一旦手工测试也通过了，测试人员会更新这个候选发布版本的状态，指示它已经通过手工测试了
10. 持续集成服务器从制品库中拿到通过验收测试的最新候选版本，将其部署到生成测试环境
11. 对这个候选发布版本进行容量测试
12. 如果成功了，将这个候选版本的状态更新为“已通过容量测试”
13. 如果部署流水线中还有后续阶段的话，一直重复这种模式
14. 一旦这个候选发布版本通过了所有相关阶段，把它标记为“可以发布”，并且任何被授权的人都能将其发布，通常是由质量保证人员和运维人员共同批准
15. 一旦发布以后，将其标记为“已发布”

4. 提交测试阶段套件的原则与实践

关于单元测试的内容，可参考另一篇文章

4.1. 避免用户界面

放到验收测试阶段处理

4.2. 使用依赖注入

4.3. 避免使用数据库

4.4. 在单元测试中避免异步

一个测试运行到异步点时，切分出来另一个测试

4.5. 使用测试替身

mock和stub

4.6. 最少化测试中的状态

持续关注“如何降低要构造测试环境的复杂性”是合理的

4.7. 时间的伪装

对于用到依赖系统时间的测试，改用stub

4.8. 蛮力

在测试套件运行过慢时，可以采用下面两个办法

• 拆分成多个测试套件，并行执行
• 将运行时间较长且不经常失败的测试放到验收测试阶段运行

这样可能导致的问题是知道问题的及时性有所降低

5. 小结

快速发现问题，快速做出反馈，快速解决问题，快快快

提交阶段虽然是部署流水线的起点，但是如果在你的流程中引入，仍然可以提供巨大的价值