GitLab CI 对 Jenkins

这是我的经验:

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

基本上他们也是这么做的，他们会在一个服务器/Docker 映像上运行一些脚本。

;

• Jenkins 更容易使用/学习，但它有成为插件地狱的风险
• Jenkins 有一个 GUI (如果它必须能够被其他人访问/维护，那么这是首选)
• 与 GitLab 的集成少于与 GitLab CI 的集成
• 詹金斯可以从你的仓库里分出来

大多数 CI 服务器都非常简单(当然、 Gitlab-ci、 圆圈、 Travis-ci、 Drone 我来、 天啊等等)。它们允许您从 YAML 文件定义执行 shell/bat 脚本。Jenkins 更容易插入，而且带有用户界面。根据您的需要，这可能是优势也可能是劣势。

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

在我看来，在 Jenkins 中链接和编排作业要比通过 YAML (调用 curl 命令)简单得多(因为有了 UI)。除此之外，Jenkins 还支持一些插件，当某些二进制文件不能在您的服务器上使用时，这些插件会安装到您的服务器上(其他的不知道)。

现在(詹金斯2号也支持更多的 Jenkinsfile和 管道插件(默认来自 Jenkins 2) ，但是过去与存储库的耦合程度比 GitLab CI 要低。

使用 YAML 文件来定义构建管道(并最终运行纯 shell/bat)更简单。

可用于 Jenkins 的插件允许您可视化所有类型的报告，例如测试结果、覆盖率和其他静态分析器。当然，您可以随时编写或使用一个工具来完成这项工作，但这对于 Jenkins 来说绝对是一个加分项(特别是对于那些倾向于过于重视这些报告的经理来说)。

最近我越来越多地与 GitLab CI 合作。在 GitLab，他们做得非常好，让整个体验充满乐趣。我理解人们使用 Jenkins，但是当您运行并可用 GitLab 时，开始使用 GitLab CI 是非常容易的。没有任何东西能像 GitLab CI 那样无缝集成，即使他们在第三方集成方面付出了相当大的努力。

• 他们的文档应该可以让您很快开始。
• 开始的门槛非常低。
• 维护容易(没有插件)。
• 缩放跑步机很简单。
• CI 完全是您资源库的一部分。
• Jenkins 的工作/观点可能会很混乱。

在写这篇文章的时候有一些额外的好处:

• 在社区版中只支持单个文件。在 企业版中支持多个文件。

我同意 Rik 的大部分观点，但是我认为 恰恰相反更简单: GitLab 被证明是一个非常棒的工具。

大部分功能来自同一产品中同一浏览器标签下的 自给自足和 整合一切: 从存储库浏览器、发布板或构建历史到部署工具和 监察。

我现在正在使用它来自动化和测试一个应用程序如何安装在不同的 Linux 发行版上，它只是 快速配置(尝试在 Firefox 中打开一个复杂的 Jenkins 作业配置，然后等待无响应脚本出现，而编辑 .gitlab-ci.yml是多么轻量级)。

由于使用了 转轮二进制程序，花在配置/缩放从服务器上的时间要少得多; 另外，在 GitLab.com中，您可以得到相当不错的免费共享运行程序。

Jenkins 觉得 手动操作是 GitLab CI 的高级用户，比如每个分支复制作业，安装插件来完成简单的事情，比如 SCP 上传。今天我所面对的唯一一个错过的用例是涉及到多个存储库的情况; 这个问题需要很好地解决。

顺便说一句，我目前正在撰写一个关于 GitLab CI 的系列文章，以演示如何使用它来配置存储库 CI 基础设施并不那么困难。上周发布的第一篇文章介绍了 与 GitLab 持续快速集成的基础知识、优缺点以及与其他工具的不同之处

首先，到目前为止，GitLab 社区版可以与 Jenkins 完全互操作。

在接下来的文章中，我将对结合 Jenkins 和 GitLab CI 的成功经验给出一些反馈。我还将讨论是否应该同时使用两个或只使用其中一个，以及使用的原因。

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

GitLab CI 和 Jenkins 的优势

GitLab 线人

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 管道。

最后的结论是: 天平倾向于一个 一点点位詹金斯，因为它的许多插件，但机会是 GitLab CI 将很快填补空白。

我想补充一些从我最近的实验 GitLab CI 的发现。11.6和11.7的特性真是太棒了！

我特别喜欢 only条件，它基本上允许您为 merge_request或 push构建单独的管道(完整的列表是 给你)

此外，我真的很喜欢没有插件。当我需要一些更复杂的功能时，我只需编写一个自定义 Docker 映像来处理所需的功能(这与您在 Drone 我来中看到的概念相同)。

如果你对 干的感兴趣，那么现在这是完全可能的! 你可以写你的“模板”,

.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！是的，它(到目前为止)不能绘制覆盖范围等等的漂亮图表，但总的来说它是一个非常整洁的工具！

extends:
- .pieceA
- .pieceB