作为DevOps流程中的一个重要组成部分，持续集成（CI）的目标是对开发团队的代码进行集成，包括代码的构建、单元测试与集成测试的执行，以及生成执行结果的报表等等。CI使开发团队无需将时间浪费在处理代码冲突的问题上，因此很多人将其视为敏捷软件开发的奠基石。
CI与持续部署（CD）过程通常是紧密联系在一起的。CD过程通过在管道中定义的步骤将由CI过程所生成的结果部署至集成、预发布乃至生产环境中。由于整个CD过程是“持续的”，因此一旦有代码签入源代码控制系统，后续过程就会自动进行测试、对代码进行构建、并将构建结果部署至目标环境中。它的优点显而易见：一方面，开发者可快速地收到bug与故障的通知，形成快速的反馈循环。另一方面，客户也将更快地使用你的新特性。
近日，Vassili van der Mersch在一篇博客文章中对各种环境中的CI工具进行了详细的比较，并分析了CI工具的未来发展。在后续的文章中，作者还将继续分析DevOps中的另一重要内容，即配置管理。
传统的CI工具
第一个正规的持续集成工具是于2001年所推出的CruiseControl，这是一个基于Java开发的开源软件。除了持续构建流程之外，它还提供了邮件通知、Ant以及对各种源代码控制系统的支持，并推出了支持.NET与Ruby的移植版本。尽管Jenkins后来居上，成为第一个得到广泛应用的CI工具，但CruiseControl已经具备了一个CI工具的基本功能，为CI过程的推广做出了很大的贡献。
Jenkins的出现与发展颇有传奇色彩，它的前身是由一位来自Sun公司的开发者川口浩介（Kohsuke Kawaguchi）于2004年开发的一个基于Java的CI工具Hudson。经过三/四年的发展后，它逐渐超越CruiseControl成为了最流行的CI工具。但自从Oracle收购了Sun之后，希望将Hudson作为收费的商业工具进行开发。以川口为首的开发者社区则决定以Jenkins的名义继续免费版本的开发。有趣的是，Hudson与Jenkins的开发者各自将对方视为自己的分支版本，而将自身视为正统。在2013年后，Jenkins的发展势头已有超越之势，它的每日提交次数远远地超越了Hudson，如今已成为市面上最流行的CI工具。
早期的Jenkins与其他传统CI一样，只支持本地托管。而现在已经有一些云计算平台推出了基于Jenkins的SaaS方案。这方面比较突出的有CloudBees，它所提供的方案是一种集成了CI与CD的混合方案，可通过Docker Pipeline插件提供对Docker容器的支持。
除了Jenkins之外，其他一些流行的CI工具还包括由JetBrains推出的TeamCity，以及由Atlassian推出的Bamboo等等。这些CI工具基本都提供了以下功能：
对源代码控制系统的支持，例如Git、Subversion、TFS等等。可以在代码控制的主线发生代码提交时自动触发后续的一系列步骤，例如构建、测试与部署等等。 对依赖管理工具的支持，如Java的Maven、NodeJS的NPM、Ruby的Gem，以及.NET的Nuget等等。 对各种类型测试的支持。早期的CI只支持单元测试，即单个对象或组件的功能验证。随后加入了对集成测试的支持，即对组件之间的通信与交互进行难。尽管如此，这还不足以验证系统确实按照用户期望的方式进行工作。因此现代化的CI工具开始支持功能性测试，将原先的手工测试替代为基于Selenium等工具的自动化测试。
云计算环境中的CI工具
曾在大规模企业中尝试过CI实践的开发者非常了解：代码的构建与测试的执行是一种非常消耗资源的操作，如果有多个团队使用同一个CI平台，那么这种情况将进一步加剧。近几年来，软件团队逐渐厌倦了本地托管的CI系统对时间与精力的要求。而基于云计算平台的SaaS解决方案的出现快速地弥补了这方面市场的缺失。
Travis CI是一个基于GitHub API所打造的托管CI服务，使用Travis CI有一个先决条件，即源代码需要在GitHub进行托管。Travis CI通过webhook对GitHub代码仓库中的各种变化进行响应，例如代码提交或pull request等等。Travis CI也依赖GitHub提供的服务对用户和组织进行认证。
使用基于云环境的CI系统让开发者得以从对本地CI系统的安装、配置过程中解脱，不必再关注于基础设施和用户认证与授权方面的问题。此外，由于大多数SaaS方案都提供了对应的API，因此整个工作流都可以实现API驱动。
基于云环境的CI系统还有另一大优势，他们通常会提供更多的测试功能，例如对不同浏览器与操作系统组合条件的测试。例如Travis就支持在Linux、Mac和Windows系统上的测试，并支持PHP、NodeJS、Go和C等各种语言。
用于移动应用的CI工具
随着智能手机的日益普及，移动应用的数量也在不断增长。但由于移动应用与Web应用相比有一些特别之处，例如它的测试与发布方式，以及完全不同的依赖管理机制，因此移动应用对于构建、测试及部署流程提出了完全不同的要求，这是传统的CI工具力所不及的。好在如今已经有几家主流的CI提供商实现了支持移动应用的CI工具，例如CircleCI已经提供了对iOS应用的支持。
移动应用的测试与Web应用具有很大的差别，Web应用的客户端多数集中在一些主流的浏览器与操作系统上，而移动应用的客户端往往是千差万别的，特别是在Android平台上。某些测试框架，例如Espresso以及Appium能够自动替你解决许多困难。而像Crashlytics与HockeyApp这样的工具除了内置的CI功能之外，还能够自动生成应用崩溃的报告，为开发者进行问题诊断提供充分的上下文。
而由于移动客户端的多样性，以集中化的方式进行所有测试的方式是不太实际的。因此，移动开发社区更推崇beta测试的方式，通过TestFairy或TestFlight等工具将潜在的新版本发布给beta测试人员。
移动应用的另一个独特之处在于它的发布方式，通常需要经过漫长而繁琐的审核流程才可发布至对应的应用商店。这不仅降低了持续交付的速度，还不得不在流程中引入各种人工步骤，使全自动化的流程无法实现。
为此，像Fastlane这样的工具可实现将应用审核流程中的大部分元素实现自动化，例如为新应用进行屏幕截图及处理认证等信息。可结合Jenkins等CI工具以完善整个工作流。
CI工具的未来
CI与CD过程如今已成为现代化应用开发中一个并不可少的元素，绝大多数开发团队在软件项目中都需要设计一个完善的CI与CD工作流。
而CI的发展并不会停下脚步，它仍处于高速的发展中。在对Web及移动项目支持的基础上，未来几年之内，我们将看到CI在其他类型的开发中的应用，例如智能手表、智能汽车以及物联网中，甚至是在虚拟现实与生物科技项目中的应用。
CI过程目前所面临的一个挑战在于在开发环境中执行的自动化测试与生产环境之间总是存在着或多或少的差别。随着近来年以Docker为代表的容器化技术在（微）服务系统中的广泛应用，CI过程也从容器的使用中受益匪浅。Docker的高可移植性使多个CI提供商开始拥抱Docker。举例来说，CircleCI就支持基于容器的应用，而CodeShip近期也推出了Jet，这是一个对Docker应用进行测试与部署的解决方案。
本文转自d1net（转载）
