持续集成、持续交付和持续部署 (CI/CD) 在开发者社区已经存在多年。一些组织让其运营部门参与进来，但很多组织并没有。对于大多数组织来说，其运营团队必须像开发人员一样熟悉 CI/CD 工具和实践。
CI/CD 实践同样适用于基础设施、第三方应用程序和内部开发的应用程序。此外，虽然工具有很多种，但都使用类似的模型。可能最重要的是，引导您的公司采用这种新实践将使您在公司中处于有利地位，并且您将成为其他人效仿的灯塔。
一些组织已经在基础设施上使用 CI/CD 实践，使用 Ansible、Chef 或 Puppet 等工具已有数年之久。 其他工具，例如 Test Kitchen，允许对最终托管应用程序的基础设施执行测试。 实际上，这些测试甚至可以将应用程序部署到类生产环境中，并在更高级的配置中使用生产负载执行应用程序级别的测试。 然而，仅仅能够单独测试基础设施就已经是一项巨大的成就。 Terraform 还可以使用 Test Kitchen 来实现比某些原始配置管理工具更短暂和幂等的基础设施配置。 添加 Linux 容器和 Kubernetes，您现在可以使用类生产的规范和资源来测试完整的基础设施和应用程序部署，这些规范和资源会在几小时而不是几个月或几年内来来去去。 一切都会在部署和再次测试之前被清除。
但是，您也可以专注于将您的网络配置或数据库数据定义语言 (DDL) 文件纳入版本控制，并开始在其上运行小型 CI/CD 管道。 也许它只是检查语法或语义或一些最佳实践。 实际上，这是大多数开发管道的开始方式。 一旦您掌握了基础架构，就更容易在其基础上进行构建。 一旦您入门，您就会开始发现管道的各种用例。
例如，我定期在公司内部撰写新闻通讯，并使用 MJML 在版本控制中对其进行维护。 我需要能够托管一个网络版本，并且有些人喜欢能够获得 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
GitLab 是 CI/CD 领域的新进入者，但它已经获得了 Forrester 持续集成工具评估报告的最高评分。 在如此拥挤且高度合格的领域中，这是一项巨大的成就。 是什么让 GitLab CI 如此出色？ 它使用 YAML 文件来描述整个管道。 它还具有一个名为 Auto DevOps 的功能，该功能允许更简单的项目自动构建管道，并内置多个测试。 该系统使用 Herokuish buildpacks 来确定语言以及如何构建应用程序。 有些语言还可以管理数据库，这对于构建新应用程序并从开发过程一开始就将其部署到生产环境来说，是一个真正的游戏规则改变者。 该系统与 Kubernetes 原生集成，并将使用多种不同的部署方法（例如基于百分比的推出和蓝绿部署）将您的应用程序自动部署到 Kubernetes 集群中。
除了其 CI 功能外，GitLab 还提供许多补充功能，例如通过与您的应用程序自动部署的 Prometheus 进行运营和监控； 使用 GitLab Issues、Epics 和 Milestones 进行的项目组合和项目管理； 内置于管道中的安全检查，结果以跨多个项目的聚合形式提供； 以及使用 WebIDE 直接在 GitLab 中编辑代码的能力，WebIDE 甚至可以提供预览或执行管道的一部分以获得更快的反馈。
GoCD
GoCD 来自 Thoughtworks 的伟大头脑，这足以证明它的能力和效率。 对我来说，GoCD 与其他工具的主要区别在于它的 价值流图 (VSM) 功能。 实际上，可以将管道链接在一起，一个管道为下一个管道提供“材料”。 这允许在部署过程中具有不同职责的不同团队提高独立性。 在将这种类型的系统引入旨在保持这些团队分离的较旧组织中，这可能是一个有用的功能，但让每个人都使用相同的工具将使以后更容易在 VSM 中找到瓶颈并重新组织团队或努力提高效率。
拥有公司中每个产品的 VSM 非常有价值。GoCD 允许以版本控制中的 JSON 或 YAML 描述，并以可视化方式呈现所有关于等待时间的数据，这使得该工具对于试图更好地了解自身的组织来说更有价值。 首先安装 GoCD 并仅使用手动审批门来绘制流程图。 然后让每个团队使用手动审批，以便您可以开始收集有关瓶颈可能存在的位置的数据。
Travis CI
Travis CI 是我第一次使用软件即服务 (SaaS) CI 系统的体验，它非常棒。这些流水线以 YAML 格式存储在您的源代码中，并与 GitHub 等工具无缝集成。我不记得上次流水线因为 Travis CI 或集成失败是什么时候了——Travis CI 的正常运行时间非常高。它不仅可以作为 SaaS 使用，而且还有一个可以托管的版本。我没有运行过那个版本——它有很多组件，而且安装所有这些组件看起来有点令人生畏。我猜想使用 Travis CI 提供的 Helm charts 将所有内容部署到 Kubernetes 会容易得多。这些 charts 尚未部署所有内容，但我相信它将来会变得更加强大。如果您不想处理这些麻烦，还有一个企业版。
但是，如果您正在开发开源代码，您可以免费使用 Travis CI 的 SaaS 版本。这是一支优秀的团队提供的优秀服务！这减轻了大量的开销，并允许您使用一个相当常见的平台来开发开源代码，而无需运行任何东西。
Jenkins
Jenkins 是最初的、受人尊敬的、事实上的 CI/CD 标准。如果您还没有读过，您需要阅读 Jenkins 的创建者兼 CloudBees 的 CTO Kohsuke 的 "Jenkins: 换档"。它总结了我过去十年对 Jenkins 和社区的所有感受。他所描述的是多年来一直需要的，我很高兴 CloudBees 正在引领这场变革。Jenkins 对于大多数非开发人员来说会有点难以接受，并且长期以来一直是其管理员的负担。但是，这些都是他们旨在解决的问题。
Jenkins 配置即代码 (JCasC) 应该有助于解决多年来困扰管理员的复杂配置问题。这将允许通过 YAML 文件零接触配置 Jenkins masters，类似于其他 CI/CD 系统。Jenkins Evergreen 旨在通过提供基于不同用例的预定义 Jenkins 配置，使此过程更加容易。这些发行版应该比普通的 Jenkins 发行版更容易维护和升级。
Jenkins 2 引入了原生流水线功能，具有两种类型的流水线，我在 LISA17 的演示中讨论了这一点。当您做一些简单的事情时，它们都不像 YAML 那样容易导航，但它们对于执行更复杂的任务来说非常好。
Jenkins X 是 Jenkins 的全面转型，并且很可能成为云原生 Jenkins 的实现（或者至少是大多数用户在使用云原生 Jenkins 时看到的东西）。它将采用 JCasC 和 Evergreen，并在 Kubernetes 上以最佳方式原生使用它们。对于 Jenkins 来说，这是一个激动人心的时刻，我期待着它的创新和在该领域的持续领导地位。
Concourse CI
我第一次接触 Concourse 是通过 Pivotal Labs 的人，当时它还是一个早期的 beta 版本——当时没有太多类似的工具。该系统由微服务组成，每个作业都在容器内运行。它最有用的一项其他工具没有的功能是能够从您的本地系统使用您的本地更改来运行作业。这意味着您可以在本地进行开发（假设您已连接到 Concourse 服务器），并像在实际构建流水线中一样运行您的构建。此外，您可以从本地系统重新运行失败的构建，并注入特定更改以测试您的修复程序。
Concourse 还有一个简单的扩展系统，它依赖于资源的基本概念。基本上，您想要为您的流水线提供的每个新功能都可以在 Docker 镜像中实现，并作为新的资源类型包含在您的配置中。这使所有功能都封装在一个单一的、不可变的工件中，可以独立升级和修改，并且破坏性更改不一定需要同时破坏您的所有构建。
Spinnaker
Spinnaker 来自 Netflix，更侧重于持续部署，而不是持续集成。它可以与其他工具集成，包括 Travis 和 Jenkins，以启动测试和部署流水线。它还与 Prometheus 和 Datadog 等监控工具集成，以便根据这些系统提供的指标来决定部署。例如，金丝雀部署使用判断概念和收集的指标来确定最新的金丝雀部署是否导致了相关指标的任何退化，并且应该回滚，或者是否可以继续部署。
与部署相关的几个额外的、独特的功能涵盖了一个在讨论持续部署时经常被忽略的领域，甚至可能看起来是相反的，但对于成功至关重要：Spinnaker 帮助使持续部署变得不那么持续。它会阻止某个阶段在特定时间运行，以防止在应用程序生命周期的关键时刻发生部署。它还可以强制执行手动批准，以确保在业务将从更改中获得最大收益时发布。事实上，持续集成和持续部署的全部意义在于准备好根据业务需要更改的速度来部署更改。
Screwdriver
Screwdriver 是一项令人印象深刻的简单工程。它使用微服务方法，并依赖于 Nomad、Kubernetes 和 Docker 等工具来充当其执行引擎。有一个相当不错的部署教程用于部署到 AWS 和 Kubernetes，但是一旦正在进行的 Helm chart 完成，它就可以得到改进。
Screwdriver 还使用 YAML 来描述其流水线，并包含许多合理的默认值，因此每个流水线的样板配置更少。该配置描述了一个高级工作流程，该工作流程可以在作业之间具有复杂的依赖关系。例如，可以保证某个作业在另一个作业之后或之前运行。作业可以并行运行，并在之后连接。您还可以使用逻辑运算符来运行作业，例如，如果任何依赖项成功或仅在所有依赖项都成功的情况下运行。更好的是，您可以指定某些作业从拉取请求触发。此外，当发生这种情况时，依赖作业不会运行，这允许轻松地隔离您的流水线，以便在应将工件投入生产时以及仍需要审查时。
这只是对这些 CI/CD 工具的简要描述——每个工具都有更多您可以调查的酷炫功能和区别。它们都是开源且免费使用的，因此请部署它们并查看哪个最适合您的需求。
3 条评论