- 理想情况下，提交阶段的运行应该少于 五分钟，一定不会超过十分钟。
- 版本控制库的主干上提交了一 次变更后，持续集成服务器会发现这次变更，并将代码签出，执行一系列的任务，包括： 编译（如果需要的话），并在集成后的源代码上运行提交测试； 创建能部署在所有环境中的二进制包（如果使用需要编译的语言，则包括编译 和组装）； 执行必要的分析，检查代码库的健康状况； 创建部署流水线的后续阶段需要使用的其他产物（比如数据库迁移或测试数据）。
- 提供快速有用的反馈
- 何时令提交阶段失败
- 精心对待提交阶段
- 让开发人员也拥有所有权
- 在超大项目团队中指定一个构建负责人
- 输入是源代码， 输出是二进制包和报告。
- 绝大多数时新的持续集成服务器都会提供一个制品库，还能设置保存多长时间之 后就自动删除那些不想要的二进制包。
- 候选发布版本在理想情况下在部署流水线中成功走向生产环境的每一步：
- 某个人提交了一次修改。
- 持续集成服务器运行提交阶段。
- 成功结束后，二进制包和所有报告和元数据都被保存到制品库中。
- 持续集成服务器从制品库中获取提交阶段生成的二进制包，并将其部署到一个类生产测试环境中。
- 持续集成服务器使用提交阶段生成的二进制包执行验收测试。
- 成功完成后，该候选发布版本被标记为“已成功通过验收测试”
- 后续从制品库中-签出通过之前所有测试的版本，来进行测试和发布
- 避免用户界面
- 使用依赖注入
- 避免使用数据库
- 在单元测试中避免异步
- 使用测试替身，模拟技术工具集，比如Mockito、Rhino、 EasyMock、JMock、NMock和Mocha等。
- 最少化测试中的状态
- 时间的伪装
- 蛮力：让提交测试在十分钟内完成。