提交阶段的运行应该少于5分钟，一定不要超过10分钏
提交阶段的首要目标是创建可部署的产物
提交阶段的原则与实践
- 提供快速有用的反馈
- 何时令提交阶段失败
- 编译错误
- 测试失败（包括单元覆盖率低于60%）
- 精心对待提交阶段
- 提交阶段中有构建用的脚本和运行单元测试、静态分析等脚本。
- 随着项目的进行，不断改进提交阶段的脚本的质量、设计和性能
- 确保将脚本做成模块化，将那些经常使用且很少变化的常见任务与需要修改的任务分开
- 将部署流水线中不同阶段所用的代码分别写在不同脚本中
- 不要写出与具体环境相关的脚本，即要把具体环境配置与构建脚本分离
- 让开发人员也拥有所有权
如果必要的话，即使是很普通的变更也都应该由开发人员和运维人员来执行 - 在超大项目团队中指定一个构建负责人
- 监督和指导对构建的维护
- 鼓励和加强构建纪律
- 在团队开始接触持续集成时，构建纪律还没建立起来时，提醒作用
- 团队成员轮流当，比如每星期轮换一次
提交阶段结果
提交阶段的输入是源代码，输出是二进制包和报告（测试结果和代码分析报告）
制品库
- 制品库仅保存某些版本，而不是全部。如果在部署流水线某个阶段失败，就可以删除该版本
- 制品库中的二进制包能够追溯到具体的代码版本控制库中的版本
- 良好的配置管理策略，二进制文件的构建过程应该是可重复的
提交测试套件的原则与实践
- 提交阶段，测试绝大部分应由单元测试组成
- 设计 能够快速运行的提交测试策略
- 运行的单元测试不应该与文件系统、数据库、库文件、框架或外部系统等交互
提交测试实践
- 避免用户界面
- 使用依赖注入
- 避免使用数据库
单元测试不应该依赖于数据库，需要把测试的代码与其存储分离开来。这就要求代码实现良好的分层，也需要使用依赖注入。如果实在无法做到，使用内存数据库 - 避免异步
- 使用测试替身
模拟技术工具集：Mockito、Rhino、EasyMock、JMock、NMock、Mocha等 - 最少化测试中的状态
降低要构造的测试环境的复杂性 - 时间的伪装
对于那些需要确保一定延时或者定时的行为，需要对其中的时间系统进行控制。作者团队的经验是，只要代码中需要使用时间，就会抽象到对系统时间服务的请求，而不是直接在业务逻辑中调用它们 - 蛮力（测试阶段运行应该少于5分钟）
- 将提交测试分成多个套件，在多台机器上并行执行（构建网格）
- 作为构建优化过程的一部分，将那些运行时间长，且不经常失败的测试放在验收测试阶段
