Vladimir Pecanac
虽然并非每个软件项目都注定会获得巨大成功，但一些软件方法和最佳实践可以提高成功几率，并让开发工作更愉快。其中现在流行的一种做法是持续集成（CI，Continuous Integration）。
持续集成最初由Grady Booch在布区方法中提出，之后成为了极限编程（extreme programming）的一部分，目的是防止集成问题堆积成为“集成地狱（integration hell）”。
接下来，我们将从以下几个方面一起了解什么是持续集成以及如何利用它：
- 什么是持续集成
- 持续集成的好处
- 持续集成的要求
- 持续集成服务器
- 对于团队的要求
- 持续交付和持续部署
- 潜在的担心
什么是持续集成
持续集成是指不断整合项目更改并进行相应的测试，通常每天至少进行一次。
马丁福勒说得很好：
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
自动化的构建、测试和部署流程可以解决软件开发项目中的许多麻烦和问题。通过可靠的方法频繁整合代码更改，可以尽早发现错误。毕竟没有人希望在demo day出现由于几个月前编写一直没有适当的机会进行合理测试而出现的任何差池。
持续集成可以解决这一痛点，它的整个流程如下图所示：
持续集成的好处
首先，降低集成风险。多数情况下，一个项目会有多个人单独处理任务或者一部分代码，人员越多，整合的风险越大，而调试、解决问题本身会是非常痛苦的，我们很可能需要大量修改代码。频繁的集成将极大减少此类问题。
第二，保障代码质量。我们可以把精力放在业务代码和功能上，从而获得更高质量的软件。
第三，有效的版本控制。如果有人提交的代码有问题，团队会即时收到通知，在有任何人拉取之前解决问题。
第四，减少团队间摩擦。明确而公正的制度流程可以减少团队之间的争吵。
第五，改善测试团队生活质量:) 通过不同版本和构建隔离并追踪错误可以有效减轻测试团队负担。
第六，部署更快。自动化可以让原本繁琐耗时的部署工作变得轻松高效。
第七，增强团队信心和士气。团队成员不必再为潜在错误可能会造成的不良后果而忧心忡忡，可以轻装上阵去创造更好的软件。
另外还有一个好处是，团队新成员可以更容易地融入整个项目之中。
持续集成的要求
落地持续集成系统，需要满足以下要求：
首先版本控制系统（VCS）必不可少，我们需要可靠的方法来集中和保存项目的所有更改。
如果我们采用的是onsite解决方案，需要有备用的服务器（至少有台虚拟机）。有一台干净的机器来构建系统非常必要。
如果我们不想把服务器或者虚拟机搞得一团糟，可以选择一些持续集成工具和解决方案，用来维护整个流程并获得更强的伸缩性。
当然从技术上来讲，持续集成工具不是必须的，就像软件开发不是必须要用IDE一样，具体怎么选择，在于我们的能力和需求。
持续集成服务器
持续集成服务器（也称为构建服务器，又称CI服务器）是一种软件工具，它包含所有持续集成操作，并为我们构建项目提供可靠和稳定的环境。一般持续集成服务器具备高度可配置性和可调整性，能够为不同平台构建各种项目。
使用持续集成服务器最好能够安装在干净的机器上，保证其在中立的环境中不受不必要的工具、环境变量和其他配置影响。如果实在没有物理机，可以考虑构建一个虚拟环境。
另外使用开发机器而不设置虚拟环境，可能会导致错误的假设和结果。把应用部署到另一台机器上时，会遇到新的问题。
持续集成服务器通常使用版本控制系统（如Subversion或Git或任何其他版本）来提取项目文件。该系统监控项目仓库，在代码成功提交时，会拉去更改并按照我们的定义来执行。完成任务后，持续集成服务器会向相关成员发送构建细节信息。检查项目的最新版本、运行构建脚本、运行测试以及发送通知是持续集成服务器的最基本功能。
除此之外，代码分析、代码覆盖率、代码质量报告、agent pooling、pipeline、构建比较、IDE集成、第三方工具支持等功能，会让持续集成服务器更加灵活好用。
对于团队的要求
相比硬件、软件或者工具，人的因素对于持续集成成功与否更为关键，这要求团队里的每个成员都能养成良好的“持续集成”习惯，例如频繁提交代码、立即修复失败构建、编写单元测试等等。
持续交付和持续部署
典型的持续集成生命周期包括构建项目、单元测试、部署测试和验收测试。一旦项目成功通过了所有阶段，就可以将其部署到生产环境中。
交付项目到生产环境中可以像其他环节一样自动完成，也可以根据业务需求手动完成。对于自动完成的情况，我们会了解到持续交付（Continuous Delivery）和持续部署（Continuous Deployment），其差异如下图所示：
潜在的担心
持续集成有很多好处，但也有人对它保持怀疑态度，主要考虑有以下几点：
增加维护成本
我们本来也需要构建、测试和部署系统。如果不用持续集成来管理这些流程的话，也需要其他的工具，否则手工和人力将在项目达到一定复杂度时捉襟见肘。
变化太大
一些认可能不太愿意在遗留系统上做太多改变，这种情况下，可以考虑逐步进行，现在小部分工作上使用持续集成。如果大家对效果满意，再引入落实到其他部分工作上。
硬件/软件成本
与维护成本及项目完成后回头解决问题的成本相比，实施持续集成的成本微不足道。
开发者已经在做这些（持续集成的）工作
开发者本可以把时间集中在更有价值的业务开发上，而不是把精力浪费在重复性工作中。
项目太小
即使是很小的项目也可以从透明的开发构成与集中的项目资源和构建中获益，许多在线持续集成工具设置起来非常简单。
持续集成工具/平台
市面上已有很多开源持续集成工具，例如我们熟悉的Jenkins，还有TeamCity、Travis CI、GO CD、Bamboo、Gitlab CI、CircleCI……等等等等。
开源PaaS Rainbond也支持持续集成，提供可扩展的CI/CD，支持Java、PHP、Python、Ruby、Node.js、Golang、Scala等源代码构建，支持代码滚动上线、一键回滚、灰度发布、AB测试，可对接Jenkins等第三方CI/CD。
进一步了解请访问Rainbond官网或试用公有云（新用户7天免费）