持续交付之三——持续集成

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

公众号，欢迎关注

第三章 持续集成

1. 引言

持续集成的目标是让软件一直处于可工作的状态

2. 实现持续集成

2.1. 准备工作

1. 版本控制
2. 自动化构建
3. 团队共识

2.2. 一个基本的持续集成系统

开发人员使用持续集成服务的简单流程

1. 查看一下是否有构建正在运行，如果有的话，等它完事，如果它失败了，就和团队的其他人把他一起修复，然后再提交代码
2. 一旦构建完成且测试完全通过，就从版本控制库中将该版本的代码更新到自己的开发环境上
3. 在自己的开发机上执行构建脚本，运行测试，以确保在你机器上的所有代码都正常工作
4. 如果本地构建成功，你提交代码
5. 然后等待你这次提交的构建结果
6. 如果失败了，停下手中的活，修复问题，转到步骤3
7. 如果成功，庆祝一下，开始下个任务吧

3. 持续集成的前提条件

3.1. 频繁提交

3.2. 全面的自动话测试套件

单元测试，集成测试，验收测试

3.3. 保持较短的构建和测试过程

频繁的执行不能占据太长时间

3.4. 管理开发工作区

开发人员开始新任务的时候，应该总是从一个已知正确的状态开始

4. 使用持续集成软件

Jenkins，CruiseControl，Go，TeamCity等

5. 必不可少的实践

5.1. 构建失败之后不要提交新代码

5.2. 提交前在本地运行所有的提交测试，或者让持续集成服务器完成此事

5.3. 等提交测试通过之后再继续工作

5.4. 回家之前，构建必须处于成功状态

如果你不想第二天被同事骂的话

5.5. 时刻准备着回滚到前一个版本

按照持续继承的流程，前一个版本肯定是没有问题的

5.6. 在回滚之前规定一个修复时间

比如说10分钟没有修复问题，就回滚

5.7. 不要将失败的测试注释掉

要么测试错了，要么改出问题了，，要么测试可以删除了，酌情处理，而不是注释掉

5.8. 为自己的导致的问题负责

5.9. 测试驱动开发

6. 推荐的实践

我们任务下面的实践也是有用的

• 若违背架构原则，就让构建失败
• 若测试运行变慢，就让构建失败
• 若有编译警告或者代码风格问题，就让测试失败

8. 小结

持续集成是部署流水线的基石，即使只采用了持续集成，也会对开发流程带来极大的改善