CI/CD 工具比较：Jenkins、GitLab CI、Buildbot、Drone 和 Concourse

介绍

持续集成、交付和部署是旨在帮助增加开发速度并发布经过充分测试的可用产品的策略。持续集成鼓励开发团队尽早测试和集成其对共享代码库的更改，以最小化集成冲突。持续交付建立在此基础上，通过消除部署或发布过程中的障碍。持续部署则进一步通过自动部署通过测试套件的每个构建。

虽然上述术语主要涉及策略和实践，但软件工具在帮助组织实现这些目标方面起着重要作用。CI/CD 软件可以帮助团队自动推进新变更通过一系列阶段，以减少反馈时间并消除流程中的摩擦。

在本指南中，我们将比较一些流行的免费开源持续集成、交付和部署服务器，旨在使协作软件开发更加简单。我们将看看 Jenkins、GitLab CI、Buildbot、Drone 和 Concourse。

Jenkins

Jenkins 是最早的开源持续集成服务器之一，至今仍是最常用的选项。最初是 Hudson 项目的一部分，但在甲骨文收购 Sun 微系统后，由于商标冲突，社区和代码库分裂。Hudson 最早发布于 2005 年，而 Jenkins 的第一个版本发布于 2011 年。

多年来，Jenkins 已经发展成为一个强大而灵活的自动化软件任务系统。Jenkins 本身主要作为一个自动化框架，其中许多重要逻辑是通过一系列插件库实现的。从监听 Web 钩子或监视存储库到构建环境和语言支持，都由插件处理。虽然这提供了很大的灵活性，但你的 CI 过程可能会依赖于许多第三方插件，这可能会很脆弱。

Jenkins 的流水线工作流程——也是通过插件提供的——是一个相对较新的添加，自 2016 年起可用。CI 过程可以使用 Groovy 语言在存储库内的文件中或通过 Jenkins Web UI 中的文本框以声明性或命令式的方式来定义。Jenkins 的一个常见批评是基于插件的配置模型和在存储库之外定义流水线或构建过程的能力有时会使得在不同的 Jenkins 实例上轻松复制配置变得困难。

Jenkins 是用 Java 编写的，并在 MIT 许可下发布。请参阅我们的指南，了解如何在 Ubuntu 16.04 上安装 Jenkins 以为项目配置 Jenkins 服务器。

GitLab CI

GitLab CI 是内置于 GitLab 中的持续集成工具，GitLab 是一个 Git 存储库托管和开发工具平台。最初作为独立项目发布，GitLab CI 在 2015 年 9 月的 GitLab 8.0 版本中与主要 GitLab 软件集成。

GitLab CI 中的 CI/CD 过程是在代码存储库中使用 YAML 配置语法定义的。然后，工作被分派到称为 runner 的机器上，这些机器易于设置，并且可以在许多不同的操作系统上进行配置。在配置 runner 时，你可以选择不同的执行器，如 Docker、shell、VirtualBox 或 Kubernetes，以确定如何执行任务。

GitLab CI 与 GitLab 存储库平台的紧密耦合对软件的使用方式有明显的影响。GitLab CI 对于使用其他存储库托管平台的开发人员来说不是一个选择。积极的一面是，集成功能允许 GitLab 用户设置 CI/CD 环境，而无需安装和学习额外的工具。通过在 Web 界面中启用一些选项、注册 runner 机器并将管道定义文件添加到存储库中，自动化测试可以开始。紧密的关系还允许你在项目之间共享 runner，自动查看存储库中的当前构建状态，并将构建产物与生成它们的代码一起保存。

GitLab 和 GitLab CI 是用 Ruby 和 Go 编写的，并在 MIT 许可下发布。你可以参考我们的指南，了解如何使用 GitLab CI 设置持续集成管道，以了解如何在 GitLab 服务器上配置此功能。

Buildbot

Buildbot 是一个提供巨大灵活性的持续集成框架。最早于 2003 年发布，作为 Mozilla 的 Tinderbox 项目的替代方案，Buildbot 主要设计为自动化跨多种平台的构建测试。

Buildbot 使用 GPL 许可发布，并使用 Python 和 Twisted 库编写。与为了简化配置而将底层语言抽象化不同，Buildbot 的配置完全使用 Python 编写。这意味着配置往往比其他系统复杂得多，但管理员有更多的空间来设计他们理想的工作流程和流程。构建的每个阶段都清晰分离且可编程。Buildbot 定位自己为一个具有构建自定义流程工具的框架，类似于 Web 框架允许你构建自定义站点。

Buildbot 作为构建测试平台的历史意味着它支持许多不同的操作系统和版本控制系统。同样，由于它是为开源测试而设计的，其架构允许用户轻松地向项目提交其首选平台的 worker 以扩展可用的测试基础。用户只需在系统上安装一些 Python 包，然后提供项目的凭据即可。

要开始使用 Buildbot 自动化构建流程，请参考我们的指南，了解如何在 Ubuntu 16.04 上安装 Buildbot。

Drone

Drone 是一个采用容器优先架构构建的现代化 CI/CD 平台。虽然上述讨论的工具都包括使用 Docker 运行构建的选项，但基于容器的工作流程是 Drone 设计的核心。Drone 使用 Go 语言编写，于 2014 年首次以 Apache 许可证发布。

Drone 充当 Docker 和存储库提供程序之间的中间协调层。与启动 CI/CD 服务器然后再连接到版本控制系统托管服务不同，Drone 需要提前获取存储库帐户信息以启动自己的身份验证、用户和权限模型。与其所有的 CI 过程一样，Drone 本身作为一个容器运行。它支持多个数据库后端和存储库提供程序，并具有内置支持使用 Let’s Encrypt 设置传输加密的 TLS/SSL 证书。

Drone 在存储库中寻找特殊的 YAML 文件以定义流水线。该语法旨在易于阅读和表达，以便存储库中的任何人都能理解持续集成过程。Drone 提供了一个插件系统，但它与 Jenkins 中的插件使用方式不同。在 Drone 中，插件是特殊的 Docker 容器，用于将预配置的任务添加到常规工作流程中。这使得通过使用一些参数调用插件而不是手动编写整个过程来完成常见任务变得更容易。在这个意义上，Drone 插件有些类似于设计用于很好地执行一个狭窄焦点任务的 Unix 实用程序命令。

要了解如何设置 Drone 服务器以自动测试您的提交，请参阅我们的在 Ubuntu 16.04 上安装和配置 Drone 的指南。

Concourse

Concourse 是一个相对较新的持续集成平台，最初于 2014 年发布。Concourse 在 CI/CD 领域的方法与我们之前看过的其他工具有很大不同，它试图尽可能地将自身排除在外，最小化状态并将每个外部因素抽象成它称为“资源”的东西。这一哲学的目标是使集成服务器完全可丢弃，以便相同的流程可以轻松地在任何 Concourse 服务器上运行。

持续集成过程的每个部分都是由模拟系统的基本原语组成的。流程的每个部分都明确定义了其依赖关系。例如，第一个任务可能需要 VCS 存储库的最新提交，而流程的后续部分可能需要最新的通过了前几个阶段的提交。通过映射每个步骤的确切依赖关系来构建流水线的这种方法导致了严格定义的行为。

为了进一步从流程中去除偶发状态，Concourse 不会在作业之间隐式传递任何内容，也不提供任何内部方式来存储构建产物。下一个阶段所需的所有信息必须明确定义，并且可能被推送到外部存储以被拉入下一个步骤。通过要求明确定义，Concourse 希望最小化系统必须考虑的假设和未知变量的数量。

Concourse 使用 Go 语言编写，并在 Apache 许可证下发布。如果您想了解如何设置 Concourse 服务器以自动化您的持续集成流程，请查看我们的在 Ubuntu 16.04 上安装 Concourse CI 的指南。