136

Jenkins 与 GitLab CI、drone.io 等其他 CI 之间的区别是什么？在一些研究中，我只能提出 GitLab 社区版不允许添加 Jenkins，但 GitLab 企业版可以。还有其他显着差异吗？

4

5 回答 5

133

这是我的经验：

在我的工作中，我们使用 GitLab EE 管理我们的存储库，并且我们有一个 Jenkins 服务器 (1.6) 正在运行。

在基础上，它们的作用几乎相同。他们将在服务器/Docker 映像上运行一些脚本。

TL;博士;

  • Jenkins 更容易使用/学习，但它有成为插件地狱的风险
  • Jenkins 有一个 GUI（如果它必须可供其他人访问/维护，这可能是首选）
  • 与 GitLab 的集成少于与 GitLab CI 的集成
  • Jenkins 可以从你的存储库中分离出来

大多数 CI 服务器都非常简单（concourse.ci）、gitlab-ci、circle-ci、travis-ci、drone.io、gocd和你还有什么）。它们允许您从 YAML 文件定义中执行 shell/bat 脚本。Jenkins 的可插拔性更强，并带有 UI。根据您的需要，这可能是优点或缺点。

由于所有可用的插件，Jenkins 是非常可配置的。这样做的缺点是您的 CI 服务器可能成为插件的意大利面。

在我看来，Jenkins 中作业的链接和编排比通过 YAML（调用 curl 命令）简单得多（因为 UI）。除此之外，Jenkins 支持插件，当它们在您的服务器上不可用时将安装某些二进制文件（其他人不知道）。

如今（Jenkins 2还支持更多的“适当的 ci”Jenkinsfile以及 Jenkins 2 中默认的pipline插件），但过去与存储库的耦合程度低于 GitLab CI。

使用 YAML 文件来定义你的构建管道（并最终运行纯 shell/bat）更干净。

Jenkins 可用的插件允许您可视化各种报告，例如测试结果、覆盖率和其他静态分析器。当然，你总是可以编写或使用工具来为你做这件事，但这对 Jenkins 来说绝对是一个加分项（尤其是对于那些往往过于重视这些报告的经理）。

最近我越来越多地使用 GitLab CI。在 GitLab，他们做得非常好，让整个体验变得有趣。我知道人们使用 Jenkins，但是当 GitLab 运行并可用时，开始使用 GitLab CI 真的很容易。没有任何东西可以像 GitLab CI 那样无缝集成，尽管他们在第三方集成方面付出了相当多的努力。

  • 他们的文档应该让您立即开始。
  • 入门门槛很低。
  • 维护很容易（没有插件）。
  • 缩放跑步者很简单。
  • CI 完全是您的存储库的一部分。
  • Jenkins 的工作/视图可能会变得混乱。

撰写本文时的一些好处：

  • 社区版仅支持单个文件。企业版中的多个文件。
于 2016-05-25T07:08:42.397 回答
65

我同意 Rik 的大部分笔记，但我对哪个更简单的看法恰恰相反：GitLab 被证明是一个很棒的工具。

大部分功能来自于自包含并将所有内容集成在同一浏览器选项卡下的同一产品中：从存储库浏览器、发布板或构建历史到部署工具和监控。

我现在正在使用它来自动化和测试应用程序如何在不同的 Linux 发行版上安装，并且它的配置速度非常快（尝试在 Firefox 中打开一个复杂的 Jenkins 作业配置并等待无响应的脚本出现 vs . 编辑多么轻巧.gitlab-ci.yml）。

由于运行器二进制文件，花在配置/缩放从属服务器上的时间要少得多；再加上在GitLab.com中您可以获得相当不错且免费的共享跑步者这一事实。

在成为 GitLab CI 的高级用户几周后，Jenkins 感觉更加手动，例如为每个分支复制作业，安装插件来完成简单的事情，例如 SCP 上传。我今天遇到的唯一一个我错过的用例是涉及多个存储库时；这需要很好地弄清楚。

顺便说一句，我目前正在写一个关于 GitLab CI 的系列文章，以展示用它来配置你的存储库 CI 基础设施并不难。上周发布的第一篇文章介绍了与其他工具的基础知识、优缺点和差异：与 GitLab CI 的快速自然持续集成

于 2017-03-08T13:02:37.717 回答
26

首先，从今天开始，GitLab 社区版可以与 Jenkins 完全互操作。没有问题。

在下文中，我将就 Jenkins 和 GitLab CI 结合的成功经验给出一些反馈。我还将讨论您应该同时使用它们还是只使用其中一个，以及出于什么原因。

我希望这将为您提供有关您自己项目的高质量信息。

GitLab CI 和 Jenkins 的优势

GitLab CI

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

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

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

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

詹金斯

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 很有可能会迅速填补这一空白。

于 2018-10-17T13:20:19.977 回答
8

我想补充一些我最近对 ​​GitLab CI 的实验结果。11.6 和 11.7 附带的功能真是太棒了！

具体来说，我喜欢only基本上允许您为merge_requestor构建单独管道的条件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"

我非常喜欢 GitLab CI！是的，它（到目前为止）无法绘制具有覆盖率等的漂亮图表，但总的来说它是一个非常简洁的工具！

编辑（2019-02-23）： 这是我在 GitLab CI 中喜欢的东西的帖子。它是在 11.7“时代”编写的，因此当您阅读此答案时，GitLab CI 可能具有更多功能。

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

extends:
 - .pieceA
 - .pieceB

查看官方文档以获取有关多个扩展的更多信息

于 2019-01-29T16:51:31.413 回答
1

如果您的构建/发布/部署和测试工作不是很复杂，那么使用 gitlab ci 具有天然优势。

由于 gitlab-ci.yml 与您的代码一起出现在每个分支中，因此您可以更有效地修改您的 ci/cd 步骤，尤其是测试（因环境而异）。

例如，您希望对任何签入到 dev 分支进行单元测试，而您可能希望在 QA 分支上执行完整的功能测试，并且在生产中进行有限的仅获取类型的测试，这可以使用 gitlab ci 轻松实现。

除了出色的 UI 之外，第二个优势是它能够使用 docker 图像来执行任何阶段，从而保持主机运行器完好无损，因此不易出错。

此外 gitlab ci 会自动为您签入，您不必单独管理 jenkins master

于 2019-09-13T06:07:42.547 回答