持续集成、持续交付和持续部署(CI/CD)在开发者社区已存在了多年。一些企业设有运维部门，但许多企业没有。对于大多数企业而言，它们的运维团队要像开发团队那样熟悉CI/CD工具和实践。

CI/CD实践同样适用于基础架构和第三方应用程序以及内部开发的应用程序。此外，有许多不同的工具，但都使用类似的模式。可能最重要的是，引导贵公司采用这种新的实践将使你在公司内有很高的威信，你会成为别人跟随的领路人。

多年来，一些组织一直对基础架构采用CI/CD实践，使用Ansible、Chef或Puppet等工具。Test Kitchen等其他工具可以在最终托管应用程序的基础架构上执行测试。事实上，那些测试甚至可以将应用程序部署到类似生产环境的环境中，针对更高级配置的生产负载执行应用程序级测试。然而，仅仅能够测试基础架构就很了不起。

与一些原始的配置管理工具相比，Terraform还可以使用Test Kitchen测试更短暂更幂等的基础架构配置。加上Linux容器和Kubernetes，你现在可以使用类似生产环境的规范和资源来测试完整的基础架构和应用程序部署，这些规范和资源在数小时内而不是数月或数年内创建和停用。一切资源在再次部署和测试之前清除干净。

然而，你还可以专注于对网络配置或数据库数据定义语言(DDL)文件进行版本控制，开始在其上面运行小型CI/CD管道。也许它只是检查语法、语义或一些最佳实践。实际上，大多数开发管道开始就是这样。一旦你搭好了脚手架，就更容易在上面构建。一旦做好准备，你将开始为管道寻找各种用例(use case)。

比如说，我经常在公司内部编写业务通讯，使用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带给大众。我认为最值得关注的计划是创建可以将Kubernetes集群变成Jenkins CI/CD平台的云原生Jenkins。

你进一步了解了这些工具并开始将这些实践带入贵公司或运维部门后，很快会有人亦步亦趋。你将提高自己和其他人的生产力。不妨更深入一点介绍这些工具。我们将简要介绍每款工具，并附有提供更多信息的链接。

项目页面：https://about.gitlab.com/product/continuous-integration/

源代码：https://gitlab.com/gitlab-org/gitlab-ce/

许可证：MIT

GitLab是CI/CD领域的新成员，但它已经成为弗雷斯特研究公司持续集成工具Wave报告的佼佼者，这在竞争如此激烈的领域实属不易。什么让GitLab CI如此出色?它使用YAML文件来描述整条管道。它还有一项名为Auto DevOps的功能，让较简单的项目可以自动构建管道，并有内置的多个测试。

该系统使用Herokuish构建包(https://github.com/gliderlabs/herokuish)来确定语言及如何构建应用程序。一些语言也可以管理数据库，这是一项真正关键的功能，用于构建新应用程序，并从开发过程一开始将它们部署到生产环境中。该系统与Kubernetes直接集成，并使用多种不同的部署方法之一自动将应用程序部署到Kubernetes集群中，比如基于百分比的部署和蓝绿部署。

除了CI功能外，GitLab还提供许多补充功能，比如运维和监控，Prometheus会与你的应用程序一起自动部署;使用GitLab Issues、Epics和Milestones，实现项目组合和项目管理;安全检查内置于管道中，结果作为多个项目的合并值来提供;以及能够使用WebIDE直接在GitLab中编辑代码，甚至可以提供管道的预览或执行部分以获得更快的反馈。

项目页面：https://www.gocd.org/

源代码：https://github.com/gocd/gocd

许可证：Apache 2.0

GoCD来自Thoughtworks的奇思妙想，这足以证明其功能和效率。对我而言，GoCD与其他工具的区别主要在于其价值流图(V**，https://www.gocd.org/getting-started/part-3/#value_stream_map)功能。实际上，管道可以串联起来，一条管道为下一条管道提供“素材”。这使得部署过程中拥有不同职责的不同团队加强了**性。将这种系统引入到打算让这些团队保持**的旧企业时，这项功能可能很有用――但让每个人使用同样的工具便于以后找到V**中的瓶颈，并重新组织团队或努力提高效率。

让公司的每个产品都有V**大有助益;GoCD允许在版本控制中以JSON或YAML来描述，并直观地显示所有数据，这使得该工具对于试图更好地了解自身的企业来说更有价值。先安装GoCD，仅使用手动批准关卡来描绘你的流程。然后让每个团队使用手动批准，以便你可以开始收集哪里存在瓶颈方面的数据。

项目页面：https://docs.travis-ci.com/

源代码：https://github.com/travis-ci/travis-ci

许可证：MIT

Travis CI是我第一次使用的软件即服务(SaaS)CI系统，它很棒。管道与源代码一起存储成YAML，并与GitHub等工具无缝集成。我不记得上次管道因Travis CI或集成而失效是什么时候了，Travis CI的正常运行时间很长。它不仅可以用作SaaS，还有可以托管的版本。我没有运行那个版本――有很多组件，安装全部组件看起来有点困难。我猜想使用Travis CI提供的Helm图表统统部署到Kubernetes会容易得多。那些图表尚未部署所有内容，但我确信将来会变得更完善。如果你不想应对麻烦，还可以使用企业版。

然而，如果你在开发开源代码，可以免费使用Travis CI的SaaS版。这是出色团队提供的出色服务!这减轻了大量开销，让你可以使用很常见的平台来开发开源代码，没必要运行任何东西。

项目页面：https://jenkins.io/

源代码：https://github.com/jenkinsci/jenkins

许可证：MIT

Jenkins是CI/CD界最正宗、最值得尊敬的事实上的标准。建议你读一下Jenkin的开发者兼CloudBees首席技术官Kohsuke撰写的《Jenkins：Shifting Gears》(https://jenkins.io/blog/2018/08/31/shifting-gears/)。它总结了过去十年我对Jenkins及社区的种种感受。他描述了多年来需要的创新，我很高兴CloudBees在这场转型中身先士卒。Jenkins对大多数非开发人员来说难度有点大，向来是管理员的一种负担。然而，这些方面是他们旨在解决的。

Jenkins配置即代码(JCasC)应该有助于解决困扰管理员多年的复杂配置问题。这便于通过YAML文件对Jenkins主机进行零接触配置，类似其他CI/CD系统。Jenkins Evergreen旨在基于不同的用例提供预定义的Jenkins配置，从而使这个过程来得更容易。与普通的Jenkins发行版相比，这些发行版应该更易于维护和升级。

Jenkins 2引入了原生管道功能，有两种类型的管道。你做一些简单的事情时，两种管道用起来都不如YAML那么容易，但它们对于完成更复杂的任务相当好。

Jenkins X堪称Jenkins的全面转型，很可能是云原生Jenkins的实现(或至少是大多数用户使用云原生Jenkins时看到的东西)。它将拿来JCasC和Evergreen，直接在Kubernetes上使用、用其所长。对Jenkins来说，眼下是激动人心的时刻，我期待着它继续创新、不断领导这个领域。

项目页面：https://concourse-ci.org/

源代码：https://github.com/concourse/concourse

许可证：Apache 2.0

我通过Pivotal Labs的人员首次接触了Concourse，那时它还是早期测试版，当时没有很多同类的工具。该系统由微服务组成，每个作业都在容器内运行。它最有用的其他工具所没有的功能之一是，能够从本地系统运行作业。这意味着你可以在本地开发(假设你连接到Concourse服务器)并运行你构建的代码，就像在真实的构建管道中运行一样。此外，你可以从本地系统重新运行失效的构建版本，并注入特定的更改来测试修复程序。

Concourse还有一个简单的扩展系统，依赖资源的基本概念。大致上来说，你希望提供给管道的每项新功能都可以在Docker镜像中实现，并作为新的资源类型包含在配置中。这使得所有功能都封装在一个可以**升级和修改的单个不可变工件中，破坏性变更未必同时　破坏所有构建版本。

项目页面：https://www.spinnaker.io/

源代码：https://github.com/spinnaker/spinnaker

许可证：Apache 2.0

Spinnaker来自Netflix，关注持续部署多过关注持续集成。它可以与其他工具集成，包括Travis和Jenkins，以启动测试和部署管道。它还与Prometheus和Datadog等监控工具集成，基于这些系统提供的度量指标做出部署方面的决策。比如说，金丝雀部署使用judge概念和收集的度量指标来确定最新的金丝雀部署是否导致相关度量指标出现任何降级、应该回滚，或确定部署是否可以继续。

与部署有关的几项额外的独特功能涵盖了讨论持续部署时常常被忽视的一个方面，这个方面看似对立，但对成功而言至关重要：Spinnaker有助于使持续部署不那么持续。它将阻止一个阶段在某些时间运行，防止部署在应用程序生命周期的关键时间内出现。它还可以执行手动审批，确保公司业务从变更获得最大的好处后才发布。实际上，持续集成和持续部署的全部意义在于，业务需求一有变化，准备好尽快部署变更。

项目页面：http://screwdriver.cd/

源代码：https://github.com/screwdriver-cd/screwdriver

许可证：BSD

Screwdriver是一款异常简单的工具。它使用微服务方法，依赖Nomad、Kubernetes和Docker等工具充当其执行引擎。有一篇很好的部署教程(https://docs.screwdriver.cd/cluster-management/kubernetes)介绍如何部署到AWS和Kubernetes，但是一旦开发中的Helm图表(https://github.com/screwdriver-cd/screwdriver-chart)完成，Screwdriver有望得到改进。

Screwdriver还使用YAML来描述管理，包含许多合理的默认值，因此每个管道的样板配置较少。配置描述了作业之间可能有复杂依赖项的高级工作流。比如说，可以保证作业在另一个作业之后或之前运行。作业可以并行运行，然后结合。比如说，如果任何依赖项成功或只有所有依赖项成功，你还可以使用逻辑运算符来运行作业。更棒的是，你可以指定从合并请求触发的某些作业。此外，发生这种情况时，依赖作业不会运行，这样工件进入到生产环境、仍需要进行审查时可以轻松隔离管道。

本文简要描述了这些CI/CD工具，每个工具有更酷的功能和差异化优势，应研究一下。它们都是开源的，可以免费使用，所以部署一下，看看哪个最符合你的要求。