持续交付（第七章）—提交阶段

在上一章中了解到如何将构建与部署脚本化，脚本通常都是帮助我们进行构建，测试，部署和发布应用的所有自动化命令集。并且在项目中脚本系统应该是一等公民。而本章的内容在之前的章节都有所提及，但是本章会更加详细的讨论如何创建有效的提交阶段和高效的提交测试。

提交阶段流程

当有人向版本控制系统的主干上提交了一次变更后，持续集成服务器会发现这次变更，并将代码签出，执行一系列的任务，包括：

• 编译
• 创建能部署在所有环境的二进制包
• 执行必要的分析，检查代码库的健康状况
• 创建部署流水线的后续阶段需要使用的其他产物

提交阶段的原则和实践

提交阶段的首要目标是要么创建可部署的产物，要么快速失败并将失败原因通知给团队，下面列出建立高效提交阶段的原则和实践。

1.提供快速有用的反馈
2.何时令提交失败
3.精心对待提交阶段
4.让开发人员也也拥有所有权
5.在超大项目团队中指定一个构建负责人

提交阶段的结果

与部署流水线的所有阶段一样，提交阶段既有输入也有输出，输入是源代码，输出是二进制包和报告。产生的报告包括测试结果和代码库的分析报告。分析报告可能包括测试覆盖率，圈复杂度，复制粘贴分析，输入输出分析。

而我们提交阶段的所有输出都会存放在制品库中，一般来说大家都会直接想到版本控制系统，但这并不是我们最好的选择，这样我们的硬盘容量会被快速的占领。我们可以使用持续集成服务器所自带的制品库进行存放。

提交测试套件的原则与重要实践

测试套件中占最多的应该是单元测试，因为它不牵扯外部系统的调用，能够及时反馈，测试覆盖率可达80%。
1.避免用户界面
2.使用依赖注入
3.避免使用数据库
4.在单元测试中避免异步
5.使用测试替身

总结

我的疑惑

• 根据之前的章节，提交至版本控制系统的代码都应该是正确可运行的，那这个时候持续集成服务器发现变更后，签出代码会跑测试么？还有必要么？，其中我觉得测试下代码覆盖率，圈复杂度是有必要。
• 构建不应该是系统自动的一个行为，为什么会有一个较差的构建系统会导致系统停止，是不是说构建也可以人为的来设计？
• 圈复杂度

谷歌结果：在软件测试的概念里，圈复杂度用来衡量一个模块判定结构的复杂程度，数量上表现为独立现行路径条数，即合理的预防错误所需测试的最少路径条数

• 复制粘贴分析
  谷歌了没有找到合适的解释，个人理解是对项目中代码的相似性做以分析。

• 输入输出分析是怎么进行分析的

• 依赖注入和内存数据库

• 桩技术和模拟技术是如何区分的，个人理解桩技术就是声明一个静可用数据。