聊一聊：你所熟知的CI／CD工具都是有哪些？

liukai · 发表于 2022-3-7 20:06:12

　　推荐一些顶级的开源CI/CD工具,这里只是对这些 CI/CD 工具的简要描述——它们都有更多很酷的特性和区别，你可以继续研究它们。它们都是开源的，可以免费使用，你可以部署它们，看看哪个最适合你的需求。xray的相关资讯可以到我们网站了解一下，从专业角度出发为您解答相关问题，给您优质的服务！

　　?

　　项目页面：

　　https://about.gitlab.com/product/continuous-integration/源代码：

　　https://gitlab.com/gitlab-org/gitlab-ce/遵循 MIT 许可协议

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

　　它使用 YAML 文件来描述整个管道。它还有一个功能叫 Auto DevOps，使比较简单的项目可以自动构建内置了若干测试的管道。使用 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 与其他工具的主要区别在于它的价值流图（VSM）特性。事实上，管道可以与管道连接在一起，为下一条管道提供“材料”。这使得部署过程中具有不同职责的团队更加独立。在希望保持团队隔离性的旧组织中引入这种类型的系统时，这可能是一个有用的特性，但是，让每个人都使用相同的工具，以后会更容易发现 VSM 中的瓶颈，那样就可以重新组织团队或工作以提高效率。

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

　　?

　　?

　　项目页面：

　　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 Charts 将它部署到 Kubernetes 会容易得多。这些 Chart 并没有把所有内容都部署，但我相信，它未来可以部署更多内容。如果你不想自己处理这些麻烦，还有一个企业版本。

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

　　?

　　?

　　项目页面：

　　https://jenkins.io/源代码：

　　https://github.com/jenkinsci/jenkins遵循 MIT 许可协议

　　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 来说，这是激动人心的时刻，我期待着它在这个领域的创新和持续的领导地位。

　　?

　　项目页面：

　　https://concourse-ci.org/源代码：

　　https://github.com/concourse/concourse遵循 Apache 2.0 许可协议

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

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

　　?

　　?

　　项目页面：

　　https://www.spinnaker.io/源代码：

　　https://github.com/spinnaker/spinnaker遵循 Apache 2.0 许可协议

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

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

　　?

　　?

　　项目页面：

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

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