前言

什么是持续集成，这个不用再说了，随便百度一下就有。持续集成到底意味着什么呢？前言中有如下的详细描述：

1. 所有开发者都现在他们自己的工作站上执行私有构建，然后再将他们的代码提交到版本控制库中，从而确保他们的变更不会导致集成构建失败。

2. 开发者每天至少向版本控制库提交一次代码。

3. 集成构建每天在一台独立的计算机上进行多次。

4. 每次构建都必须100%通过测试。

5. 生成可以进行功能测试的产品（如WAR、配件、可执行程序等）。

6. 修复失败的构建是优先级最高的事情。

7. 某些开发者复查构建生成的报告，如编码标准报告和依赖分析报告，寻找可以改进的地方。

对照我们现在的状况，2还没有度量，4和6并没有完全被遵守，还是有不少不符合的地方，需要持续改进，不过难的是如何改变开发人员的意识。

第1章 启程

针对每次变更构建软件。

想法：现在我们还没做到每次代码提交就触发一次构建，仍然还只是定时触发的，这样可能多个人的代码提交会被合并在一起。这主要是由于机器资源不足导致流程构建时间过长，另外大家还并未全部养成原子提交的习惯。

最后的问题，可以思考一下：

您怎样才知道自己正在正确地进行CI？以下问题可以帮助您确定项目中做得不够的地方。

1. 是否使用版本控制库（或SCM工具）？

2. 项目的构建过程是否已经自动化并可重复？它完全不需要干预吗？

3. 是否编写并执行自动化的测试？

4. 执行测试是否是构建过程的一部分？

5. 如何确定编码标准和设计标准？

6. 哪一种反馈机制是自动化的？

7. 是否使用独立的集成计算机进行软件构建？

想法：很长时间以来，我们的持续集成没有自动化测试，也就只是持续编译和持续检查。不过自动化测试确实逐渐多起来了，也有开发团队感受到了它的好处，并且愿意主动去做，会越来越好的。

第2章 引入持续集成

经常提交代码

不要提交无法构建的代码

立即修复无法集成的构建

编写自动化的开发者测试

必须通过所有测试和审查

执行私有构建

避免签出无法构建的代码

CI作为品质的中心工作：有些人将CI看作简单地将软件组件放在一起的过程。我们把CI看作软件开发的中心工作，因为它通过每次变更执行构建，保证了软件的健康。检查软件的品质就是检查最新的集成构建，就这么简单。

提纲挈领，态度鲜明，不过有时要推行起来似乎不是这么简单，尤其是CI纪律部分。要如何让研发团队感受到CI的价值呢？

CI的价值是什么？从大的方面来说，CI的价值在于：

1. 减少风险：缺陷的监测和修复变得更快；软件的健康程度可以测量；减少假定；

2. 减少重复过程。

3. 在任何时间、任何地点生成可部署的软件。

4. 增强项目的可见性：有效地决策；注意到趋势。

5. 对开发团队的软件产品建立起更强大的产品信心。

这些好处，哪些是一线开发人员能感知到的？哪些是项目经理层面感知到的？

什么阻碍了团队使用CI？

1. 增加了维护CI系统的开销。

其实是把后面要做的事情提到前面做了，会让大家觉得要做的事情变多了。

2. 变化太大。

推荐循序渐进的推进CI，比如先进行日构建，然后逐渐增加频率。

3. 失败的构建太多。

主要原因是提交代码之前没有进行私有构建，确实是的。

4. 额外的硬件/软件成本。

这确实是个开销，不过机器的成本其实要比人力成本低得多。

5. 开发者应该执行这些动作。

是持续编译还是持续集成？

我曾经与一些正在实现CI的组织机构一起工作，有时候我听到他们说：“是的，我们有CI。”当然，我认为，“这很棒！”然后问了几个问题。你们的测试达到多少代码覆盖率？执行构建需要多长时间？你们平局的代码复杂度如何？有多少代码重复？你们在版本控制系统中对构建版本打上标签了吗？你们将已部署的软件存放在哪里？

我发现他们移植在做的其实更像是“持续编译”，他们安装了像CruiseControl这样的工具轮询版本控制库中的变更。当它监测到变更时，它就从中去除源代码，进行编译，如果出现问题就发出一封电子邮件。在一台单独的计算机上自动地编译软件系统要好过什么都不做，但并不能提供全功能的CI系统锁带来的好处。

对照一下，我们确实还有很多可改进的地方。

CI如何与其他开发实践配合？

1. 开发者测试。

开发人员编写的自动化测试。

2. 坚持编码标准。

这方面我们做得还不错，CheckStyle/PMD/findbugs/cppcheck等工具一直都在使用。

3. 重构。

4. 小发行版本。

5. 共同拥有代码。

让构建保持“亮绿灯”

我发现对于有效使用CI有两个测量指标：提交的次数和构建的状态。每个开发者（或两个结对的开发者）每天至少应该向版本控制库提交一次，签入的次数通畅说明了变更的大小（更多的提交通畅意味着更小的变更，这是好事）。在一天的大多数时候，您的构建状态应该是“亮绿灯”（通过），要让整个团队都重视这一点。我们有时候会得到“亮红灯”的构建，但重要的是尽快让它回到“亮绿灯”的状态。不要让您的团队习惯先处理别的项目任务，再去处理等待的红灯。如果放着红灯状态不管而去做其他工作，就会削弱CI的好处。

很有效的CI指示器。

---

我是有底线的