以持续集成工具实现 DevOps 之禅

作为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 应用进行测试与部署的解决方案。

感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。