（点击
上方公众号
，可快速关注）
来源：waylau，
waylau.com/why-we-need-continuous-integration/
如有好文章投稿，请点击 → 这里了解详情
持续集成（Continuous Integration），也就是我们经常说的 CI，是现代软件开发技术的基础。本文论述了当前软件开发过程中存在的问题，讲解了持续集成、持续集成服务器的概念，最终探讨了为什么我们需要持续集成来解决这些问题。
当前软件开发过程存在的问题
在没有应用持续集成之前，传统的开发模式是这样的：
-
项目一开始是先划分好模块，分配模块给相应的开发人员；
-
开发人员开发好一个模块就进行单元测试；
-
等所有的模块都开发完成之后，由项目经理对所有代码进行集成；
-
集成后的项目由项目经理部署到测试服务器上，被交由测试人员进行集成测试；
-
测试过程中出现 Bug 就提把问题记录进行 Bug 列表中；
-
项目经理分配 Bug 给相应的责任人进行修改；
-
修改完成后，项目经理再次对项目进行集成，并部署到测试服务器上；
-
测试人员在下一次的集成测试中进行回归测试；
-
通过通过之后就部署到生产环境中；
-
如果测试不通过，则重复上述“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试”工作。
这个过程中可能会出现如下问题：
1. Bug 总是在最后才发现
随着软件技术的发展，软件规模也在扩大，软件需求越来越复杂，软件已经不能简单地通过划分模块的方式来开发，往往需要在项目内部互相合作，模块之间存在一定的依赖关系，那么早期就存在的 Bug 往往会在最后集成的时候才被发现。
2. 越到项目后期，问题越难解决
很多开发者需要在集成阶段花费大量的时间来寻找 Bug 的根源，加上软件的复杂性，问题的根源很难定位。而且我们都清楚，间隔的时间越久，Bug 修复的成本越高，因为连开发人员自己都忘了当初写得是什么鬼代码，从而不得不从头阅读代码、理解代码。
3. 软件交付时机无法保障
正是因为我们无法及时修复 Bug，或者是没能在早期就修复 Bug，从而令整个修复 Bug 的周期拉长了。不管怎么样，我们不可能把明知存在 Bug 的软件交付给客户。
而且，大量没有在前期预估到的工作量产生了——开发人员不得不花费大把时间在查找 Bug 上；测试人员不断的需要进行回归测试；项目经理不得不疲命于该死的代码的集成、部署这些重复性工作——最终导致整个项目的周期拉长，交付时间点往后拖。
4. 程序经常需要变更
某些项目，程序会经常需要变更，特别是敏捷开发的实践者。由于产品经理在与客户交流过程中，往往实际的软件就是最好的原型，所以软件会被当作原型作为跟客户交流的工具。当然，客户最希望的当然是客户的想法能够马上反映到原型上，这会导致程序会经常被修改的。那么也就意味着“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试”工作无形又爆增了。
5. 无效的等待变多
有可能开发在等集成其他人的模块；测试人员在等待开发人员修复 Bug；产品经理在等待新版本上线好给客户做演示；项目经理在等待其他人提交代码。不管怎么样，等待意味低效。
6. 用户的满足度低
这里的用户是广义的，可以指最终的客户，也可以是产品经理、公司领导、测试人员，甚至可能是开发人员自己。你想想看，本来三个月做完的项目被拉长到了九个月甚至一年，用户能满意吗！产品经理、公司领导经常需要拿项目作为演示的原型，结果告诉我在演示前一刻发现还有很多 Bug 没有解决，项目启动不了无法访问，这叫人情何以堪。
持续集成、持续集成服务器的概念
那么好了，在上面论述的这些问题中，我们发现有些工作是无法避免的，比如测试工作、修改程序、集成工作、部署工作。但其实在整个工作流程上，是存在可以优化的空间的，比如，集成测试的工作是否可以提前做？可否有自动化的手段来代替测试、集成、部署工作？围绕这些，软件行业的大师们提出“持续集成”口号。
1. 什么是持续集成、持续集成服务器
在软件工程中，持续集成（CI）是指将所有开发者工作副本每天多次合并到主干的做法。 Grady Booch 在1991年的 Booch method 中首次命名并提出了 CI 的概念，尽管在当时他并不主张每天多次集成。而 XP（Extreme programming，极限编程）采用了 CI 的概念，并提倡每天不止一次集成。
而持续集成服务器就是能够采用自动化的手段，来解放人的双手，实现项目持续集成的工具。与之配套的软件有 TeamCity、Jenkins、Go 等。
2. 怎么样才算是“持续”
对于一天需要集成多少次数，并没有一个明确的定义。一般就是按照自己项目的实际需要来设置一定的频率，少则可能几次，多则可能达几十次。可以设置按照代码的变更来触发集成，或者设置一个固定时间周期来集成，也可以手工点击集成的按钮来“一键集成”。
3. 持续集成的工作流程
-
当开始更改代码时，开发人员会从代码库（如 SVN、Git 等）获取当前代码库的副本。
-
当其他开发人员将更改的代码提交到代码库时，此副本将逐渐停止反映代码库中的代码。代码分支保持检出的时间越长，当开发人员分支重新集成到主线时，多个集成冲突和故障的风险就越大。
-
当开发人员向代码库提交代码时，他们必须首先更新他们的代码，以反映代码库中的最新更改。
-
当存储库与开发人员的副本不同，他们必须要花时间来先处理冲突。
持续集成的好处
1. 解放了重复性劳动
自动化部署工作可以解放了集成、测试、部署等重复性劳动，而且机器集成的频率明显可以比手工的高很多。
2. 更快地修复问题
由于持续集成更早的获取变更，更早的进入测试，也就能更早的发现问题，解决问题的成本显著下降。
3. 更快地交付成果
及早集成、及早测试减少了缺陷遗留到部署环节的机会。在某些情况下，更早地查找错误还会减少解决错误所需的工作量。
如果集成服务器对代码进行构建过程中发现错误，可以及时发送邮件或者短信提供给开发人员进行修复。
如果集成服务器在部署环节发现当前版本有问题不可用，集成服务器会将部署回退到上一个版本。这样服务器上始终都会有一个可用的版本。
4. 减少手工的错误
人与机器的一个最大的区别是，在重复性动作上，人容易犯错，而机器犯错的几率几乎为零。所以，当我们搭建完成集成服务器后，以后的事就交给集成服务器来打理吧。
5. 减少了等待时间
持续集成缩短了从开发、集成、测试、部署各个环节的时间，从而也就缩短了中间可以出现的等待时间。持续集成，意味着开发、集成、测试、部署也得以持续。
6. 更高的产品质量
集成服务器往往提供 Code review、代码质量检测等功能。对代码不规范或者有错误的地方会进行标识，也可以设置邮件、短信等进行告警。而开发人员通过 Code review 也可以持续提高编程的能力。
持续集成的最佳实践
1. 频繁检出代码
为了让你本地的副本和代码库中的版本最小差异化，建议频繁检出代码。有时候代码冲突无可避免，但最小差异化最容易解决。而且，越早发现的问题，解决成本也最低。
2. 频繁提交代码
这个与第1条的原理类似，频繁提交代码，可以让其他人的检出副本和代码库中的版本最小差异化。
3. 减少分支，回归主干
虽然代码管理工具都支持分支的概念，但应尽量减少其使用。假设有多个分支并行，应及早将变更集成到主干中，而不是同时维护软件的多个版本。主干作为软件开发的工作版本。
4. 使用自动化构建
可以使用 Maven、Ant 等来实现自动化构建，这些工具可以帮助你在构建过程中实现自动化测试。前提是你有写单元测试用例，比如 JUnit 等。
5. 提交自测
在提交工作之前，每个程序员必须本地集成所有的代码，做一个完整的构建和运行，并通过所有单元测试。这样就减少了集成测试在集成服务器上构建失败的风险。
