GitLab CI 与詹金斯
GitLab CI vs. Jenkins
Jenkins 与其他 CI 之间有什么区别，例如 GitLab CI、drone.io 随 Git 发行版一起提供。在一些研究中，我只能得出 GitLab 社区版不允许添加 Jenkins，但 GitLab 企业版可以。还有其他显着差异吗？
这是我的经验：
在我的工作中，我们使用 GitLab EE 管理我们的存储库，并且我们有一个 Jenkins 服务器 (1.6) 运行ning。
在基础上他们做的几乎一样。他们将 运行 一些脚本放在 server/Docker 图像上。
TL;DR;
- Jenkins 比较容易use/learn，但是有成为插件地狱的风险
- Jenkins 有一个 GUI（如果必须被其他人 accessible/maintainable，这可以是首选）
- 与 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 also supports more "proper ci" with the Jenkinsfile and the pipline 插件默认来自 Jenkins 2），但过去与存储库的耦合程度低于 GitLab CI.
使用 YAML 文件定义构建管道（最终 运行ning pure shell/bat）更干净。
Jenkins 可用的插件允许您可视化各种报告，例如测试结果、覆盖率和其他静态分析器。当然，您始终可以编写或使用工具来为您完成这项工作，但这对 Jenkins 来说绝对是一个加分项（尤其是对于那些倾向于过于重视这些报告的经理）。
最近我越来越多地使用 GitLab CI。在 GitLab，他们做得非常出色，让整个体验变得有趣。我知道人们使用 Jenkins，但是当你拥有 GitLab 运行ning 并且可用时，GitLab CI 上手真的很容易。没有任何东西可以像 GitLab CI 那样无缝集成，尽管他们在第三方集成方面付出了很多努力。
- 他们的文档应该可以让您立即入门。
- 入门门槛很低
- 维护简单（无插件）。
- 缩放 运行 用户很简单。
- CI 完全是您存储库的一部分。
- Jenkins jobs/views 会变得混乱。
撰写本文时的一些好处：
- 社区版只支持单个文件。 enterprise edition.
中的多个文件
我同意 Rik 的大部分笔记，但我认为哪个更简单相反：GitLab 被证明是一个很棒的工具。
大部分功能来自 独立 和 integrating everything in the same product under the same browser tab: from repository browser, issue board or build history to deployment tools and monitoring。
我现在正在使用它来自动化和测试应用程序在不同 Linux 发行版上的安装方式，并且 配置速度非常快（尝试打开在 Firefox 中进行复杂的 Jenkins 作业配置并等待非响应脚本出现与编辑的轻量级相比.gitlab-ci.yml)。
花在 configuring/scaling slaves 上的时间大大减少了，这要归功于 runner binaries; plus the fact that in GitLab.com 你得到了相当不错的免费共享跑步者。
Jenkins 在成为 GitLab CI 的超级用户数周后感觉 更加手动 ，例如每个分支复制作业，安装插件来做一些简单的事情，比如 SCP 上传。我今天遇到的唯一一个我想念它的用例是涉及多个存储库时；这还需要很好地弄清楚。
顺便说一句，我目前正在撰写有关 GitLab CI 的系列文章，以展示使用它配置存储库 CI 基础设施并不难。上周发布，第一篇介绍基础知识，优缺点和与其他工具的区别：Fast and natural Continuous Integration with GitLab CI
首先，从今天开始，GitLab 社区版可以与 Jenkins 完全互操作。没问题。
接下来，我将结合 Jenkins 和 GitLab 的成功经验给出一些反馈 CI。我还将讨论您应该同时使用还是仅使用其中一个，以及出于什么原因。
我希望这能为您提供有关您自己的项目的优质信息。
GitLab CI 和 Jenkins 的优势
GitLab CI
GitLab CI 自然集成在GitLab SCM中。您可以使用 gitlab-ci.yml 文件创建管道并通过图形界面操作它们。
这些作为代码的管道显然可以存储在代码库中，强制执行 "everything as code" 实践（访问、版本控制、可再现性、可重用性等）。
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 倾斜 一点点 因为它有很多插件，但 GitLab CI 很可能会很快填补这个空白。
我想补充一些我最近对 GitLab CI 进行实验的发现。 11.6 和 11.7 附带的功能非常棒！
特别是我喜欢 only 条件，它基本上允许您为 merge_request 或 push 构建单独的管道（完整列表为 here）
此外，我真的很喜欢没有插件。当我需要一些更复杂的功能时，我只需编写一个自定义 Docker 图像来处理所需的功能（这与您在 drone.io 中看到的概念相同）。
如果您想 DRY，现在绝对有可能！你可以写下你的 "templates,"
.myTemplate:
image: node:10.14.2
script:
- npm install
- npm run test
将它们放入某个 public 存储库，将它们包含在主管道中：
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 "era" 中编写的，因此当您阅读此答案时，GitLab CI 可能具有更多功能。
编辑 (2019-07-10): Gitlab CI 现在支持多个 extends 例如
extends:
- .pieceA
- .pieceB
查看官方文档以获取有关 multiple extends
的更多信息
如果您的 build/publish/deploy 和测试工作不是很复杂，那么使用 gitlab ci 具有天然的优势。
由于 gitlab-ci.yml 与代码一起出现在每个分支中，因此您可以更有效地修改 ci/cd 步骤，尤其是测试（因环境而异）。
例如，您希望对任何签入开发分支进行单元测试，而您可能希望在 QA 分支上进行全面的功能测试，并在生产环境中进行有限的仅获取类型的测试，这可以轻松使用gitlab ci.
除了出色的 UI 之外的第二个优势是它能够使用 docker 图像来执行任何阶段，从而保持主机运行器完好无损，因此不易出错。
而且 gitlab ci 会自动为你签入，你不必单独管理 jenkins master
Jenkins 与其他 CI 之间有什么区别，例如 GitLab CI、drone.io 随 Git 发行版一起提供。在一些研究中，我只能得出 GitLab 社区版不允许添加 Jenkins，但 GitLab 企业版可以。还有其他显着差异吗？
这是我的经验：
在我的工作中，我们使用 GitLab EE 管理我们的存储库，并且我们有一个 Jenkins 服务器 (1.6) 运行ning。
在基础上他们做的几乎一样。他们将 运行 一些脚本放在 server/Docker 图像上。
TL;DR;
- Jenkins 比较容易use/learn，但是有成为插件地狱的风险
- Jenkins 有一个 GUI（如果必须被其他人 accessible/maintainable，这可以是首选）
- 与 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 also supports more "proper ci" with the Jenkinsfile and the pipline 插件默认来自 Jenkins 2），但过去与存储库的耦合程度低于 GitLab CI.
使用 YAML 文件定义构建管道（最终 运行ning pure shell/bat）更干净。
Jenkins 可用的插件允许您可视化各种报告，例如测试结果、覆盖率和其他静态分析器。当然，您始终可以编写或使用工具来为您完成这项工作，但这对 Jenkins 来说绝对是一个加分项（尤其是对于那些倾向于过于重视这些报告的经理）。
最近我越来越多地使用 GitLab CI。在 GitLab，他们做得非常出色，让整个体验变得有趣。我知道人们使用 Jenkins，但是当你拥有 GitLab 运行ning 并且可用时，GitLab CI 上手真的很容易。没有任何东西可以像 GitLab CI 那样无缝集成，尽管他们在第三方集成方面付出了很多努力。
- 他们的文档应该可以让您立即入门。
- 入门门槛很低
- 维护简单（无插件）。
- 缩放 运行 用户很简单。
- CI 完全是您存储库的一部分。
- Jenkins jobs/views 会变得混乱。
撰写本文时的一些好处：
- 社区版只支持单个文件。 enterprise edition. 中的多个文件
我同意 Rik 的大部分笔记，但我认为哪个更简单相反：GitLab 被证明是一个很棒的工具。
大部分功能来自 独立 和 integrating everything in the same product under the same browser tab: from repository browser, issue board or build history to deployment tools and monitoring。
我现在正在使用它来自动化和测试应用程序在不同 Linux 发行版上的安装方式，并且 配置速度非常快（尝试打开在 Firefox 中进行复杂的 Jenkins 作业配置并等待非响应脚本出现与编辑的轻量级相比.gitlab-ci.yml)。
花在 configuring/scaling slaves 上的时间大大减少了，这要归功于 runner binaries; plus the fact that in GitLab.com 你得到了相当不错的免费共享跑步者。
Jenkins 在成为 GitLab CI 的超级用户数周后感觉 更加手动 ，例如每个分支复制作业，安装插件来做一些简单的事情，比如 SCP 上传。我今天遇到的唯一一个我想念它的用例是涉及多个存储库时；这还需要很好地弄清楚。
顺便说一句，我目前正在撰写有关 GitLab CI 的系列文章，以展示使用它配置存储库 CI 基础设施并不难。上周发布，第一篇介绍基础知识，优缺点和与其他工具的区别：Fast and natural Continuous Integration with GitLab CI
首先，从今天开始，GitLab 社区版可以与 Jenkins 完全互操作。没问题。
接下来，我将结合 Jenkins 和 GitLab 的成功经验给出一些反馈 CI。我还将讨论您应该同时使用还是仅使用其中一个，以及出于什么原因。
我希望这能为您提供有关您自己的项目的优质信息。
GitLab CI 和 Jenkins 的优势
GitLab CI
GitLab CI 自然集成在GitLab SCM中。您可以使用 gitlab-ci.yml 文件创建管道并通过图形界面操作它们。
这些作为代码的管道显然可以存储在代码库中，强制执行 "everything as code" 实践（访问、版本控制、可再现性、可重用性等）。
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 倾斜 一点点 因为它有很多插件，但 GitLab CI 很可能会很快填补这个空白。
我想补充一些我最近对 GitLab CI 进行实验的发现。 11.6 和 11.7 附带的功能非常棒！
特别是我喜欢 only 条件，它基本上允许您为 merge_request 或 push 构建单独的管道（完整列表为 here）
此外，我真的很喜欢没有插件。当我需要一些更复杂的功能时，我只需编写一个自定义 Docker 图像来处理所需的功能（这与您在 drone.io 中看到的概念相同）。
如果您想 DRY，现在绝对有可能！你可以写下你的 "templates,"
.myTemplate:
image: node:10.14.2
script:
- npm install
- npm run test
将它们放入某个 public 存储库，将它们包含在主管道中：
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 "era" 中编写的，因此当您阅读此答案时，GitLab CI 可能具有更多功能。
编辑 (2019-07-10): Gitlab CI 现在支持多个 extends 例如
extends:
- .pieceA
- .pieceB
查看官方文档以获取有关 multiple extends
的更多信息如果您的 build/publish/deploy 和测试工作不是很复杂，那么使用 gitlab ci 具有天然的优势。
由于 gitlab-ci.yml 与代码一起出现在每个分支中，因此您可以更有效地修改 ci/cd 步骤，尤其是测试（因环境而异）。
例如，您希望对任何签入开发分支进行单元测试，而您可能希望在 QA 分支上进行全面的功能测试，并在生产环境中进行有限的仅获取类型的测试，这可以轻松使用gitlab ci.
除了出色的 UI 之外的第二个优势是它能够使用 docker 图像来执行任何阶段，从而保持主机运行器完好无损，因此不易出错。
而且 gitlab ci 会自动为你签入，你不必单独管理 jenkins master