持续交付（第三章）—持续集成

在上一章中了解到如何对项目的配置进行管理，这是项目开发的一个基础步骤，对于团队的协作，版本的重现都是起很重要的作用的。在本章中继续学习又一实践——持续集成，顾名思义就是让项目在每次的提交之后都要进行构建，运行，跑一遍测试。

持续集成

为什么要使用持续集成

在很多软件项目中，都有一个通病，即在开发过程中，应用程序在相当一段时间内无法运行。究其原因，没有人有兴趣在开发完成之前运行整个应用。所以他们会给后期的集成阶段留出很长时间，这样的集成活动可能会持续很长时间，而最糟糕的则是没有人知道到底要画多长时间。
而持续集成就是解决这类问题的灵丹妙药了，持续集成要求每当有人提交代码时，就对整个应用进行构建，并对其执行全面的自动化测试集合，若有失败，则最快解决至可运行状态。这样下来，在后期我们就可以花费很少的时间将软件交付给用户。

实现持续集成

持续集成是一种实践，而非工具。要在项目中实现持续集成，我们需要下面这些准备工作。

1.版本控制
2.自动化构建
3.团队共识
4.一个基本的持续集成系统

并且也要遵循以下的实践

1.频繁提交
2.创建全面的自动化套件
3.保持较短的构建和测试流程
4.管理开发区

持续集成中需要注意

1.构建失败之后不要提交新的代码
2.提交前在本地运行所有的提交测试，或者让持续集成服务器完成此事
3.等提交测试通过后再继续工作
4.回家之前，构建必须处于成功状态
5.时刻准备回滚上一个版本
6.在回滚之前要规定一个修复时间
7.不要将失败的测试注释掉
8.为自己导致的问题负责
9.测试驱动开发

总结

可能这一章中的一些实践之前使用过，在看得时候相对之前很好理解，收获很大，疑惑相对就变少了。

我的收获

• 持续集成可以有效减少项目周期
• 持续集成也是有相应的软件
• 测试驱动开发，Test First

我的疑惑

• 当团队中人数众多时，不停push,pull 合并分支，解决冲突，这样会不会降低生产效率