GitLab CI与Jenkins的比较

Question

Jenkins和其他CI工具（例如带有Git发行版的GitLab CI、drone.io）之间的区别是什么？在一些研究中，我只找到了GitLab社区版不允许添加Jenkins，但是GitLab企业版可以。还有其他重要的区别吗？

- Ravikiran butti

---

GitLab现在还制作了一份GitLab CI与Jenkins的比较：https://about.gitlab.com/comparison/gitlab-vs-jenkins.html - bbodenmiller

新链接为：https://about.gitlab.com/comparison/pdfs/gitlab-vs-jenkins.pdf - Guillaume Husta

Answer 1

这是我的经验：

在我的工作中，我们使用GitLab EE管理我们的存储库，并运行一个Jenkins服务器（1.6版本）。

基本上它们做的事情差不多。它们将在服务器/Docker镜像上运行一些脚本。

简而言之：

- Jenkins更易于使用/学习，但有成为插件地狱的风险。 - Jenkins有图形用户界面（如果需要被其他人访问/维护，则可以使用此选项）。 - 与GitLab CI相比，与GitLab的集成程度较低。 - Jenkins可以从您的存储库中拆分出来。

大多数CI服务器都很简单明了（concourse.ci, gitlab-ci, circle-ci, travis-ci, drone.io, gocd等）。它们允许您从YAML文件定义中执行shell/bat脚本。Jenkins更具可插拔性，并带有用户界面。这可能是优点或缺点，具体取决于您的需求。

由于存在许多插件，Jenkins非常可配置。这样做的缺点是，您的CI服务器可能变成插件的混杂物。

在我看来，在Jenkins中链接和编排作业要比通过YAML（调用curl命令）简单得多（因为有UI）。此外，Jenkins支持安装某些二进制文件的插件，当它们在您的服务器上不可用时会自动安装（对于其他服务器是否也支持该功能我并不清楚）。

现在（Jenkins 2 也支持更多的“proper ci”，其中包括 Jenkinsfile 和 pipline 插件，这是从 Jenkins 2 开始默认支持的），但过去与代码库的耦合度要低于 GitLab CI。使用 YAML 文件来定义构建流程（最终运行纯 shell/bat）更加清晰。Jenkins 提供的插件可以帮助您可视化各种报告，例如测试结果、覆盖率和其他静态分析器。当然，您总是可以编写或使用工具来为您完成此操作，但对于 Jenkins 而言，这肯定是一个优点（特别是对于那些倾向于高度重视这些报告的管理人员而言）。最近我越来越多地使用 GitLab CI。在 GitLab 中，他们正在做出真正出色的工作，使整个体验变得有趣。我知道人们使用 Jenkins，但是当您使用并可用 GitLab CI 时，很容易开始使用 GitLab CI。即使他们花费了相当多的精力进行第三方集成，也没有任何东西能够像 GitLab CI 那样无缝集成。

• 他们的文档可以让您立即开始。
• 开始门槛非常低。
• 维护很容易（无需插件）。
• 扩展Runner很简单。
• CI完全成为您的存储库的一部分。
• Jenkins工作/视图可能会变得混乱。

写作时的一些福利：

• 社区版仅支持单个文件。企业版支持多个文件。

- Rik

---

Jenkins现在可以通过Blue Ocean获得更好的GUI界面。 - Ayoub Kaanich

从GitLab 9.3开始，增加了支持多项目管道。这是我坚持使用Jenkins的主要原因之一。目前我正在进行概念验证，以检查是否可以通过GitLab进行管理，因为他们显然也在专注于此，并且发展得更快。除此之外，我真的很喜欢它的用户界面以及它随着时间的推移而发展的方式。 - Rik

使用YAML文件的好处在于，您可以将更改记录在应该直接记录的地方 - 存储库中作为源代码的一部分。因此，您可以为不同的发布分支拥有具有不同YAML文件的分支。当然，合并YAML可能会很麻烦 :) 想象一下在Jenkins中合并两个流水线，这是一项更加困难的工作。 - Christian Müller

Jenkins提供的工具比GitLab CI多得多。如果设置得当，GitLab / Jenkins Together集成是可能的，并且对用户来说非常透明。在您的存储库中使用Jenkinsfile很容易合并两个管道......您将需要GitLab和GitLab源分支插件。 - sancelot

“仅支持社区版中的单个文件。企业版支持多个文件。”这句话是什么意思？很抱歉，我尝试阅读附带的问题，但无法理解关联性。 - Lester

Answer 2

我同意Rik的大多数观点，但是我认为更简单的是相反的：GitLab证明是一个与之一起工作的精彩工具。

大部分的能力来自于它的自包含性和将所有内容整合到同一个产品中，在同一个浏览器选项卡下：从仓库浏览器、问题板或构建历史到部署工具和监控。

我现在正在使用它来自动化和测试应用程序在不同Linux发行版上的安装方式，它只需要极少的配置时间（尝试在Firefox中打开复杂的Jenkins作业配置并等待无响应的脚本出现，然后编辑.gitlab-ci.yml的轻便程度）。

由于runner二进制文件，配置/扩展从机所需的时间显著减少；此外，在GitLab.com上，您可以获得相当不错且免费的共享runner。

在成为GitLab CI的高级用户几周后，Jenkins感觉更手动，例如根据分支复制作业、安装插件以执行简单的操作，如SCP上传。我目前遇到的唯一用例是涉及多个存储库的情况；这些需要好好处理。

顺便说一下，我目前正在编写有关GitLab CI系列的文章，以演示配置存储库CI基础架构并不那么困难。上周发布了第一篇，介绍了基础知识、优缺点和与其他工具的区别：使用GitLab CI进行快速和自然的持续集成

- Alfageme

---

我完全同意你对Gitlab的看法。在写这篇文章时，Gitlab还没有现在这么完善。我非常喜欢Gitlab作为一个工具，并且真的很感激开发人员为此所做的一切努力。 - Rik

@alfageme：我会查看你在提到的网站上的报告。无论如何：感谢你们所有人的解释。此刻，我将决定我们是否使用GitLab CI或Jenkins来进行CI相关工作。 - Max Schindler

@Rik，我确实喜欢Gitlab CI，但我听到一些反对者说很难维护yaml文件，因为缺乏可重用性，因为管道中的许多yaml文件都遵循相同的结构，并且模板不被视为优于jenkinsfile，因为jenkinsfile使用groovy。因此，它关乎代码与配置之间的可重用性。你能分享一下你的想法吗？ - user1870400

@user1870400 我不太确定你所说的模板是什么意思。因为我所看到的，它只是您存储库中的一个文件。这与您的 Jenkinsfile 没有区别。您是正确的，在您的 Jenkinsfile 中，您可以使用 Groovy（+其他 Java 库）来运行代码，而 .gitlab-ci.yaml 文件将主要支持 shell，但这取决于 runner 的位置。 另一方面，您也可以从 shell 脚本中调用所有这些内容，但缺点是您正在创建机器依赖项（在我看来并不是非常透明）。 - Rik

@Alfageme - 我开始使用Gitlab CI，并逐渐远离Jenkins。目前我将其用于自动构建、上传到Nexus、部署到DEV环境和运行单元测试。这样的序列是在项目级别（标准）执行的。在DEV之后，我还需要管理多个项目（Gitlab组）的部署。我创建了一个GUI界面，使用Gitlab、Nexus API等，您可以选择要部署的项目的最新标签，同时也会部署组项目的最新标签（简陋）。我正在开发扩展，支持版本矩阵定义（projec1v1.1与project2v3.2兼容），我会在gitlab上提出一个功能请求。 - kensai

Answer 3

首先，截至今日，GitLab社区版可以与Jenkins完全互操作，毫无疑问。

接下来，我将分享一些成功结合Jenkins和GitLab CI的经验，并讨论您是否应该同时使用它们或仅使用其中之一以及原因。

希望这能为您自己的项目提供优质信息。

GitLab CI和Jenkins的优势

GitLab CI

GitLab CI在GitLab SCM中自然集成。 您可以使用gitlab-ci.yml文件创建管道，并通过图形界面操纵它们。

这些管道作为代码显然可以存储在代码库中，强制执行“一切皆为代码”的实践（访问、版本控制、可重现性、可重用性等）。

GitLab CI是一个很棒的可视化管理工具：

• 团队的所有成员（包括非技术人员）都可以快速轻松地访问应用程序生命周期状态。
• 因此，它可以用作发布管理的交互式和操作性仪表板。

Jenkins

Jenkins是一个很棒的构建工具。它的优势在于其众多插件。尤其是，我在使用Jenkins和其他CI或CD工具之间的接口插件方面非常幸运。这总是比重新开发两个组件之间的对话界面（可能很糟糕）更好。

可以使用groovy脚本来实现管道即代码。

GitLab CI与Jenkins一起使用

一开始听起来可能有点多余，但是将GitLab CI和Jenkins结合起来非常强大。

• GitLab CI编排（串联、运行、监视……）管道，其中一个好处是可以利用其与GitLab集成的图形界面。
• Jenkins运行作业并促进与第三方工具的对话。

这种设计的另一个好处是工具之间的松耦合：

• 我们可以替换任何构建工厂组件，而不必重新设计整个CI/CD流程。
• 我们可以拥有异构构建环境，结合（可能有几个）Jenkins、TeamCity等，仍然拥有单一的监控工具。

权衡取舍

当然，这种设计需要付出代价：初始设置繁琐，并且您需要对许多工具有最低水平的了解。

出于这个原因，我不建议这样的设置，除非

• 您有许多第三方工具要处理。那就是Jenkins用其许多插件非常方便的地方。
• 您必须处理具有异构技术的复杂应用程序，每个应用程序都有不同的构建环境，并且仍然需要统一的应用程序生命周期管理UI。

如果您不处于这两种情况之一，只选择其中一个工具会更好，而不是同时使用。

如果必须选择一个

GitLab CI和Jenkins都有优缺点，两者都是强大的工具。那么该如何选择呢？

答案1

选择团队（或身边人）已经掌握一定水平的工具。

答案2

如果您对CI技术完全没有经验，只需选择其中一个并开始使用。

• 如果您正在使用GitLab，并且熟悉“一切皆代码”，选择GitLab CI是完全合理的。
• 如果您需要与其他许多CI / CD工具进行对话或者绝对需要GUI构建作业，请选择Jenkins。

那些正在使用GitLab但不确定是否会继续使用它的用户仍然需要记住，选择GitLab CI会意味着放弃所有CI / CD流水线。

最后的结论是：由于Jenkins具有许多插件，它的平衡略微倾向于Jenkins，但GitLab CI很快就会填补这一差距。

- avi.elkharrat

---

@Peter Mortensen：谢谢！ - avi.elkharrat

Answer 4

我想分享一些最近在使用GitLab CI时的发现。11.6和11.7版本提供的功能非常棒！

特别是我喜欢only条件，它基本上允许您为merge_request或push构建单独的流水线（完整列表在这里）。

此外，我真的很喜欢没有插件的存在。当我需要更复杂的功能时，我只需编写一个处理所需功能的自定义Docker镜像（这与您在drone.io中看到的概念相同）。

如果您想了解DRY，现在绝对可以实现！您可以编写自己的“模板”，

.myTemplate:
  image: node:10.14.2
  script:
    - npm install
    - npm run test

将它们放入公共存储库中，并将其包含在主要流水线中：

include:
  - remote: https://....

并使用它们来扩展一些工作：

test:
  extends: .myTemplate
  only:
    refs: ["master"]
    variables:
      - $CI_PIPELINE_SOURCE == "push"

"I love GitLab CI so much!"，虽然它（迄今为止）不能用覆盖率等绘制漂亮的图表，但总体而言，它是一个非常不错的工具！

编辑（2019-02-23）：这里是我关于喜欢GitLab CI的事情的帖子。它是在11.7“时代”编写的，所以当您阅读此答案时，GitLab CI可能有更多功能。

编辑（2019-07-10）：Gitlab CI现在支持多个extends，例如。

extends:
 - .pieceA
 - .pieceB

请查阅官方文档了解有关多继承的更多信息。

- Stepan Vrany

Answer 5

如果您的构建/发布/部署和测试工作不是非常复杂，那么使用GitLab CI具有天然的优势。由于gitlab-ci.yml与每个分支中的代码一起存在，因此您可以更有效地修改ci/cd步骤，特别是测试（在不同环境中有所不同）。例如，您想对任何dev分支的提交进行单元测试，而您可能希望在QA分支上执行完整的功能测试，并且仅在生产环境中进行限定类型的测试，可以使用GitLab CI轻松实现这一点。除了出色的UI之外，第二个优势是其能够使用Docker镜像执行任何阶段，保持主机运行程序的完整性，从而减少错误。此外，GitLab CI会自动为您检入代码，无需单独管理Jenkins主节点。

- Rajanikant Patel