持续集成、持续交付和持续部署（CI/CD）在开发社区中已经存在多年。有些组织已经有相应的运营工具，但许多没有。对于大多数组织来说，运营团队必须像开发团队一样熟悉 CI/CD 工具和实践。

CI/CD 实践对于基础设施、第三方应用程序和内部开发的应用程序同样适用。虽然有许多不同的工具可以实践 CI/CD，但这些工具都使用类似的模型。最重要的也许是，引导公司采取这种新的做法会让你在公司里处于一个强有力的地位，成为别人前进的灯塔。

有些团队多年来一直在基础设施上使用 CI/CD 实践，借助类似 Ansible、Chef 或 Puppet 这样的工具。其他工具，如 Test Kitchen，允许在最终将托管应用程序的基础设施上执行测试。

事实上，这些测试甚至可以将应用程序部署到类似于生产的环境中，使用生产负载在更高的配置上执行应用程序级测试。然而，能够单独测试基础设施就是一个巨大的成就。Terraform 还可以使用 Test Kitchen 实现比一些原始配置管理工具更加短暂的幂等基础设施配置。再加上 Linux 容器和 Kubernetes，你现在就可以使用与生产环境类似的规范和资源测试完整的基础设施和应用程序部署，这些资源的使用和释放只需几个小时，而不是几个月或几年。在重新部署和测试之前，所有内容都会被删除。

但是，你还可以致力于将网络配置或数据库数据定义语言（DDL）文件放到版本控制系统中，并开始在这些文件上运行小型的 CI/CD 管道。也许只是检查语法、语义或一些最佳实践。实际上，大多数开发管道都是这样开始的。一旦你搭好脚手架，它就比较容易构建了。一旦开始，你就会开始找到各种各样的管道用例。

例如，我经常在公司内编写时事通讯，并使用 MJML 在版本控制系统中维护它。我需要能够托管一个 Web 版本，有些人希望获得 PDF，于是，我构建了一个管道。现在，当我新建一条时事通讯时，我会在 GitLab 中提交一个合并请求。这会自动创建 index.html，其中包含到时事通讯的 HTML 和 PDF 版本的链接。HTML 和 PDF 文件也在管道中创建。在有人来查看这些工件之前，它们不会发布。然后，GitLab Pages 发布网站，我可以获取 HTML 并作为时事通讯发送。将来，当合并请求被合并或经过特殊的审批步骤后，我将自动发送时事通讯。这看起来很简单，但是它节省了我很多时间。这正是这些工具能够为你做的主要的事情。它们会节省你的时间。

关键是要创建可以抽象工作的工具，这样它们就可以在几乎不做更改的情况下应用于多个问题。我也应该指出一点，我创建的内容几乎不需要任何代码，只需要一些轻量级的 HTML 模板、一些用于循环遍历 HTML 文件的节点，以及一些用于操作包含所有 HTML 页面和 PDF 的索引页的节点。

其中一些看起来可能有点复杂，但是大部分都是从我使用的不同工具的教程中获得的。许多开发人员很乐意与你一起从事这类工作，因为他们在完成这些工作时也会发现它们很有用。我提供的链接是一个我们计划针对 DevOps KC 推出的时事通讯，所有创建网站的代码都来自于我在内部时事通讯上所做的工作。

下面列出的许多工具可以提供这种类型的交互，但是有些工具提供的模型稍有不同。这个领域中出现的模型是使用类似 YAML 这样的东西对管道进行声明性描述，其中每个阶段都是短暂且幂等的。许多系统还通过在管道的不同阶段创建有向无环图（DAG）来确保正确的排序。

这些阶段通常在 Linux 容器中运行，可以做你在容器中所能做的任何事情。一些工具，如 Spinnaker，只关注部署组件，并提供一些其他工具通常不包含的操作特性。Jenkins 通常以 XML 格式保存管道，大多数交互都发生在 GUI 中，但是，最近的实现使用了 Groovy 和领域专属语言（DSL）。此外，Jenkins 作业通常在安装了特殊 Java 代理的节点上执行，包含各种插件和预安装组件。

Jenkins 在其工具中引入了管道，但是它们使用起来有些困难，并且包含了一些警告说明。最近，Jenkins 的创建者决定让社区朝着几个不同的方向发展，希望能够为这个项目注入新的活力——使其成为可以将 CI/CD 真正带给大众的项目。我认为最有趣的是创建一个原生云 Jenkins，它可以将一个 Kubernetes 集群转变为 Jenkins CI/CD 平台。

当你进一步了解这些工具并开始将这些实践引入公司或运营部门时，你很快就会有追随者。你会提高自己和别人的工作效率。我们都有多年的积压工作要做——如果你能给他们足够的时间来处理这些积压工作，你的同事会多么喜欢呢？当你的应用程序可靠性的不断提高时，在下一次薪资谈判或面试时你就有了话语权。

让我们更深入地研究下这些工具。我们将对每一个工具进行简要地介绍，并分享可以让你了解更多信息的链接。

GitLab 是 CI/CD 领域的一个新手玩家，但它已经在 Forrester Wave 持续集成工具中占据了领先地位。在这样一个竞争对手众多而水平又很高的领域，这是一项巨大的成就。是什么让 GitLab CI 如此了不起？

除了 CI 功能之外，GitLab 还提供了许多补充功能，比如自动把 Prometheus 和你的应用程序一起部署，实现运行监控；使用 GitLab 问题（Issues）、史诗（Epics）和里程碑（Milestones）进行项目组合和项目管理；管道内置了安全检查，提供跨多个项目的聚合结果；使用 WebIDE 在 GitLab 中编辑代码的能力，它甚至可以提供预览或执行管道的一部分，以获得更快的反馈。

GoCD 出自 Thoughtworks 的大师之手，这足以证明它的能力和效率。对我来说，GoCD 与其他工具的主要区别在于它的价值流图（VSM）特性。

事实上，管道可以与管道连接在一起，为下一条管道提供“材料”。这使得部署过程中具有不同职责的团队更加独立。在希望保持团队隔离性的旧组织中引入这种类型的系统时，这可能是一个有用的特性，但是，让每个人都使用相同的工具，以后会更容易发现 VSM 中的瓶颈，那样就可以重新组织团队或工作以提高效率。

为公司的每个产品都配备 VSM 是非常有价值的；GoCD 允许在版本控制系统中以 JSON 或 YAML 的形式对其进行描述，并以可视化的方式显示所有有关等待时间的数据，这使得这个工具对于想更好地理解自己的组织的人更有价值。从安装 GoCD 开始，只需要借助手动审批门（manual approval gates）就可以完成流程映射。然后让每个团队使用手动审批，这样你就可以开始在可能存在瓶颈的地方收集数据。

Travis CI 是我第一次使用软件即服务（SaaS） CI 系统，它非常棒。管道以 YAML 的形式存储在源代码中，可以与 GitHub 等工具无缝集成。我不记得上一次由于 Travis CI 或集成而导致管道失败是什么时候了——Travis CI 的正常运行时间非常长。它不仅可以作为 SaaS 使用，而且还有一个可以托管的版本，我还没有运行这个版本，因为它有很多组件，安装起来似乎有点困难。

我觉得，用 Travis CI 提供的 Helm Charts 将它部署到 Kubernetes 会容易得多。这些 Chart 并没有把所有内容都部署，但我相信，它未来可以部署更多内容。如果你不想自己处理这些麻烦，还有一个企业版本。

但是，如果你正在开发开源代码，那么就可以免费使用 Travis CI 的 SaaS 版本。这是一个很棒的团队提供的很棒的服务！这会大幅降低开销，并且允许你使用一个相当通用的平台来开发开源代码，而无需运行任何东西。

Jenkins 是 CI/CD 领域中一款最早的、久负盛名的工具，是事实上的标准。对于大多数非开发人员来说，Jenkins 可能会是一个不小的负担，并且长期以来也一直是其管理员的负担。然而，这些都是他们想要解决的事项。

Jenkins 配置即代码（JCasC）应该有助于解决困扰管理员多年的复杂配置问题。和其他 CI/CD 系统类似，它允许通过 YAML 文件实现 Jenkins 主节点的零接触配置。Jenkins Evergreen 的目标是通过提供基于不同用例的预定义 Jenkins 配置来简化这个过程。这些发行版应该比标准的 Jenkins 发行版更容易维护和升级。

Jenkins 2 引入了具有两种管道类型的原生管道功能。当你在做一些简单的事情时，这两种方法都不像 YAML 那么容易操作，但是它们非常适合处理更复杂的任务。

Jenkins X 是 Jenkins 的彻底转变，很可能是原生云 Jenkins 的实现（或者至少是大多数用户在使用原生云 Jenkins 时会看到的东西）。它将使用 JCasC 和 Evergreen，并在 Kubernetes 本地以最佳的方式使用它们。对于 Jenkins 来说，这是激动人心的时刻，我期待着它在这个领域的创新和持续的领导地位。

我第一次听说 Concourse 是通过 Pivotal Labs 的同事介绍的，那是一个早期的 Beta 版本——当时还没有多少类似的工具。该系统由微服务组成，每个作业在一个容器中运行。它独家提供的一个最有用的特性是：从本地系统（可进行本地修改）运行一项作业的能力。这意味着你可以在本地进行开发（假设你已经连接到 Concourse 服务器），并像在实际构建管道中那样运行构建。此外，你还可以从本地系统重新运行失败的构建，并注入特定的更改来测试修复程序。

Concourse 还有一个简单的扩展系统，它以资源这个基本概念为基础。基本上，你希望向管道提供的每个新特性都可以在 Docker 镜像中实现，并作为新的资源类型包含在配置中。这使得所有的功能都封装在一个单一的不可变工件中，可以独立地升级和修改，而破坏更改并不一定要同时破坏所有的构建。

Spinnaker 来自 Netflix，它更侧重于持续部署而不是持续集成。它可以与其他工具集成，包括 Travis 和 Jenkins，以启动测试和部署管道。它还集成了 Prometheus 和 Datadog 等监控工具，根据这些系统提供的指标可以进行部署决策。例如，金丝雀部署使用判断的概念和收集的指标来确定最新的金丝雀部署是否导致了相关指标的下降，是否应该回滚，或者是否可以继续部署。

与部署相关的一些额外的、独特的特性涵盖了我们在讨论持续部署时经常忽略的一个领域，甚至可能看起来正相反的领域，但对于成功来说却至关重要：Spinnaker 可以使持续部署不那么持续。它可以阻止某个阶段在特定时间运行，从而防止部署在应用程序生命周期的关键时刻发生。它还可以强制手动审批，以确保在业务可以从更改中获得最大收益的时候发布。事实上，持续集成和持续部署的全部要点是准备好在业务需要更改时尽快部署变更。

Screwdriver 是一个非常简单的工程。它使用微服务方法，并依赖 Nomad、Kubernetes 和 Docker 等工具作为执行引擎。对于到 AWS 和 Kubernetes 的部署，它提供了一个很好的部署教程，但是，一旦进行中的 Helm Charts 完成，它就可以得到改进。

Screwdriver 还将 YAML 用于其管道描述，并包含许多合理的默认设置，因此，每个管道的样板配置都比较少。该配置描述了一个高级工作流，作业之间可以有复杂的依赖关系。例如，可以保证一个作业在另一个作业之后或之前运行。作业可以并行运行，然后进行连接。你还可以使用逻辑操作符来运行作业，例如，如果作业的任何依赖项成功，或者只有所有依赖项都成功。更便利的是，你可以指定从 pull 请求触发的特定作业。此外，当这种情况发生时，从属作业不会运行，这使你可以很容易地隔离管道，以确定工件何时应该投入生产，何时仍然需要进行评审。

本文只是对这些 CI/CD 工具的简要描述——它们都有更多很酷的特性和区别，你可以继续研究它们。它们都是开源的，可以免费使用，你可以部署它们，看看哪个最适合你的需求。

• https://opensource.com/article/18/12/cicd-tools-sysadmins