Jenkins 与 GitLab CI、drone.io 等其他 CI 之间的区别是什么？在一些研究中，我只能提出 GitLab 社区版不允许添加 Jenkins，但 GitLab 企业版可以。还有其他显着差异吗？
【问题讨论】：
标签： git jenkins gitlab gitlab-ci drone.io
这是我的经验：
在我的工作中，我们使用 GitLab EE 管理我们的存储库，并且我们有一个 Jenkins 服务器 (1.6) 正在运行。
在基础上，它们的作用几乎相同。他们将在服务器/Docker 映像上运行一些脚本。
TL;DR;
大多数 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 和 pipline 插件默认来自 Jenkins 2），但过去与存储库的耦合程度低于 GitLab CI。
使用 YAML 文件来定义您的构建管道（并最终运行纯 shell/bat）更简洁。
Jenkins 可用的插件允许您可视化各种报告，例如测试结果、覆盖率和其他静态分析器。当然，您始终可以编写或使用工具来为您执行此操作，但这对 Jenkins 来说绝对是一个加分项（尤其是对于那些往往过于重视这些报告的经理）。
最近我越来越多地使用 GitLab CI。在 GitLab，他们做得非常好，让整个体验变得有趣。我知道人们使用 Jenkins，但是当 GitLab 运行并可用时，开始使用 GitLab CI 真的很容易。没有任何东西可以像 GitLab CI 那样无缝集成，尽管他们在第三方集成方面付出了相当多的努力。
撰写本文时的一些福利：
【讨论】：
我同意 Rik 的大部分笔记，但我认为哪个更简单相反：GitLab 被证明是一个很棒的工具。
大部分功能来自于在同一浏览器选项卡下的同一产品中独立和integrating everything：从存储库浏览器、发布板或构建历史到部署工具和monitoring .
我现在正在使用它来自动化和测试应用程序如何在不同的 Linux 发行版上安装，而且它只是配置速度非常快（尝试在 Firefox 中打开一个复杂的 Jenkins 作业配置并等待出现无响应的脚本与编辑.gitlab-ci.yml 的轻量级。
由于runner binaries，花在配置/扩展从属服务器上的时间大大减少了；再加上在GitLab.com 中，您可以获得相当不错且免费的共享跑步者。
Jenkins 在成为 GitLab CI 的高级用户几周后感觉更加手动，例如每个分支复制作业，安装插件来做简单的事情，比如 SCP 上传。我今天遇到的唯一一个我错过的用例是涉及多个存储库时；这需要很好地弄清楚。
顺便说一句，我目前正在写一个关于 GitLab CI 的系列文章，以展示使用它来配置您的存储库 CI 基础设施并不难。上周发布，第一篇介绍了基础知识、优缺点以及与其他工具的区别：Fast and natural Continuous Integration with GitLab CI
【讨论】：
Jenkinsfile 相比，这并没有什么不同。你是对的，在你的Jenkinsfile 中你有 groovy（+ 额外的 java 库）可用于运行代码，.gitlab-ci.yaml 文件将主要支持 shell，但是（取决于运行器的位置）。另一方面，您也可以从 shell 脚本调用所有这些，但缺点是您正在创建机器依赖项（我认为这不是很透明）。
首先，从今天开始，GitLab 社区版可以与 Jenkins 完全互操作。没问题。
在下文中，我就结合 Jenkins 和 GitLab CI 的成功经验给出一些反馈。我还将讨论您应该同时使用它们还是只使用其中一个，以及出于什么原因。
我希望这将为您提供有关您自己项目的高质量信息。
GitLab CI
GitLab CI 自然地集成在 GitLab SCM 中。您可以使用gitlab-ci.yml 文件创建管道并通过图形界面对其进行操作。
这些作为代码的管道显然可以存储在代码库中，从而强制执行“一切皆为代码”的做法（访问、版本控制、再现性、可重用性等）。
GitLab CI 是一款出色的可视化管理工具：
詹金斯
Jenkins 是一个很棒的构建工具。它的优势在于它的许多插件。特别是，我在使用 Jenkins 和其他 CI 或 CD 工具之间的接口插件方面非常幸运。这总是比重新开发（可能很糟糕）两个组件之间的对话界面更好的选择。
使用groovyscripts 也可以使用管道即代码。
一开始听起来可能有点多余，但是将 GitLab CI 和 Jenkins 结合起来非常强大。
这种设计的另一个好处是工具之间的耦合松散：
当然，这种设计是要付出代价的：初始设置很麻烦，而且您需要对许多工具有最低限度的了解。
因此，我不推荐这样的设置，除非
如果你不属于这两种情况，你可能最好只使用其中一种，但不要同时使用。
GitLab CI 和 Jenkins 各有利弊。两者都是强大的工具。那么选择哪一个呢？
回答 1
选择您的团队（或身边的人）已经具备一定水平的 专业知识。
答案 2
如果您都是 CI 技术的大一新生，只需选择一个即可开始学习。
那些正在使用 GitLab 但不确定他们是否会继续这样做的人仍然必须记住，选择 GitLab CI 将意味着丢弃所有 CI / CD 管道。
最后一句话是：由于 Jenkins 有很多插件，天平有点倾向于 Jenkins，但 GitLab CI 很有可能会很快填补这一空白。
【讨论】：
我想补充一些我最近对 GitLab CI 进行实验的发现。 11.6 和 11.7 附带的功能真是太棒了！
我特别喜欢only 条件，它基本上允许您为merge_request 或push 构建单独的管道（完整列表为here）
另外，我真的很喜欢没有插件。当我需要一些更复杂的功能时，我只需编写一个自定义 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)： here's my post about GitLab CI 中我喜欢的东西。它是在 11.7“时代”编写的，因此当您阅读此答案时，GitLab CI 可能具有更多功能。
编辑（2019-07-10）： Gitlab CI 现在支持多个extends，例如
extends:
- .pieceA
- .pieceB
查看官方文档以获取有关multiple extends的更多信息
【讨论】：
如果您的构建/发布/部署和测试作业不是很复杂，那么使用 gitlab ci 具有天然优势。
由于 gitlab-ci.yml 与您的代码一起出现在每个分支中，您可以更有效地修改您的 ci/cd 步骤，尤其是测试（因环境而异）。
例如，您希望对任何签入到 dev 分支进行单元测试，而您可能希望在 QA 分支上执行完整的功能测试，并且在生产中进行有限的仅获取类型的测试，这可以使用 gitlab ci 轻松实现.
除了出色的 UI 之外，第二个优势是它能够使用 docker 图像来执行任何阶段，从而保持主机运行器完好无损，因此不易出错。
而且 gitlab ci 会自动为你签到，你不必单独管理 jenkins master
【讨论】：