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

介绍

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

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

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

詹金斯

Jenkins 是最早的开源持续集成服务器之一，并且仍然是当今最常用的选项。最初是 Hudson 项目的一部分，在收购原始开发商 Sun Microsystems 后，社区和代码库因与 Oracle 发生商标冲突而分裂。 Hudson 最初于 2005 年发布，而 Jenkins 的第一个版本是在 2011 年发布的。

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

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

Jenkins 是用 Java 编写的，并在 MIT 许可下发布。按照我们关于如何在 Ubuntu 16.04 上安装 Jenkins 的指南为您的项目配置 Jenkins 服务器。

GitLab CI

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

GitLab CI 中的 CI/CD 流程是使用 YAML 配置语法在代码存储库本身的文件中定义的。然后将工作分派到称为 runner 的机器上，这些机器易于设置并且可以在许多不同的操作系统上进行配置。配置运行器时，您可以在 Docker、shell、VirtualBox 或 Kubernetes 等不同的执行器之间进行选择，以确定任务的执行方式。

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

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

构建机器人

Buildbot 是一个持续集成框架，提供了极大的灵活性。 Buildbot 于 2003 年首次发布，作为 Mozilla 的 Tinderbox 项目的替代品，其主要设计目的是为了在各种平台上自动进行构建测试。

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

Buildbot 作为构建测试平台的历史意味着它支持许多不同的操作系统和版本控制系统。同样，由于它在设计时考虑了开源测试，因此其架构允许用户轻松地将带有他们喜欢的平台的工作人员提交给项目，以扩展可用的测试基础。用户只需在系统上安装几个 Python 包，然后向项目提供凭据。

要开始使用 Buildbot 来自动化构建过程，请按照我们关于如何在 Ubuntu 16.04 上安装 Buildbot 的指南进行操作。

无人机

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

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

Drone 在存储库中查找用于管道定义的特殊 YAML 文件。该语法旨在易于阅读和表达，以便使用存储库的任何人都可以理解持续集成过程。 Drone 提供了一个插件系统，但它的使用方式与 Jenkins 中的不同。在 Drone 中，插件是特殊的 Docker 容器，用于将预配置的任务放入常规工作流程中。这使得通过使用一些参数调用插件而不是手动编写整个过程的脚本来更容易完成常见任务。从这个意义上说，Drone 插件有点类似于 Unix 实用命令，这些命令旨在很好地完成一项狭隘的任务。

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

大厅

Concourse 是一个相对较新的持续集成平台，最初于 2014 年发布。 Concourse 处理 CI/CD 空间的方法与我们研究过的其他工具有很大不同，因为它试图尽可能地将自己排除在等式之外，最小化状态并将每个外部因素抽象成它称为“资源”的东西. 这种理念的目标是使集成服务器完全一次性，以便相同的进程可以轻松地在任何 Concourse 服务器上运行。

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

为了进一步从流程中移除附带状态，Concourse 不会在作业之间隐式传递任何内容，并且不提供任何存储构建工件的内部方式。必须明确定义下一阶段所需的所有信息，并可能将其推送到外部存储以进入下一步。通过要求明确的定义，Concourse 希望最大限度地减少系统必须考虑的假设和未知变量的数量。

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

结论

持续集成、交付和部署软件是复杂的自动化系统，旨在使您的流程可靠且可重复。从上面的描述中可以看出，关于如何最好地完成自动化测试和发布有许多不同的想法，重点放在等式的不同部分。没有一种工具可以满足每个项目的需求，但是有这么多高质量的开源解决方案可用，您很有可能找到一个满足您团队需求的系统。