持续交付12-提交阶段

提交阶段

提交阶段是持续集成的开始,也是持续集成的最小集.每次修改都会触发自动化构建,将构建的二进制包,执行测试和进行一些分析和后续环境准备操作;

解决什么问题

部署流水线的入口.确保项目花费最少的实践做代码级别的集成;它能驱动一些好的设计实践,并对代码质量和交付速度产生很大的影响;
具体处理事情:

1. 编译,并在集成后的源代码进行提交测试;
2. 创建可部署到所有环境的二进制包;
3. 执行必要的分析,检查代码库的健康状况;
4. 创建部署流水线的后续阶段需要使用的其他产物;(如数据库迁移和数据准备)

怎么做

提交阶段的原则和实践

1. 提供快速有用的反馈.越早发现错误信息,越容易解决.运行异常是否要立即停止要看异常类型,如果造成程序无法运行的异常,阶段肯定要停止进行修改处理;如果非流程异常,则需要执行完当前阶段,统一反馈测试结果;
2. 何时令提交阶段失败.除了流程异常外(编译错误,测试失败,环境问题),是否让阶段失败需要团队对于代码质量的评估形成共识.比如重复代码数量的阈值;编译警告数量的多少等;
3. 精心对待提交阶段.开发中不断改进脚本的质量,设计和性能.如果脚本变大就要进行模块化拆分,来保障一个良好的脚本结构.
4. 让开发人员拥有所有权.强调开发人员应该参与到流水线各个阶段中,便于问题定位和修复;
5. 在超大项目团队中指定一个构建负责人.目的是约束和监管构建原则,避免走样.构建负责人可以轮流找人负责;

提交阶段的产出

1. 制品库.二进制包和结果报告应该单独管理,不能放到版本控制库中.原因如下:
   1. 二进制包文件比较大,会让版本控制库难以管理;
   2. 制品库是特殊的版本控制系统.它只保存某些测试成功版本,而不是全部;
   3. 制品库中二进制包具备可追溯性,可以关联到版本控制库;
   4. 二进制包可重复生成;
2. 部署流程
   

提交测试套件的原则和实践

提交阶段测试主要是单元测试和一些功能验收测试.单元测试要尽量简单,不与外部交互(文件系统,数据库,库文件,框架或外部系统等);

1. 避免用户界面.用户界面会比较灵活,不利于单元测试
2. 使用依赖注入.组合模式,需要测试时引入对应的依赖类即可
3. 避免使用数据库.依赖数据库执行性能不高;应用和数据的隔离性
4. 在单元测试中避免异步.
5. 使用测试替身.使用一些mock工具来模拟依赖服务进行测试.
6. 最少化测试中的状态.避免测试结构复杂化
7. 时间的伪装.通过包装类来避免直接依赖外部服务时间.
8. 测试时长.要进行测试时长控制,因为这会影响开发人员的测试积极性.加速方式有两种:1进行组件拆分2优化构建流程,将长时间执行的测试移到验收测试中