Jenkins与Git发行版附带的其他CI（例如GitLab CI，drone.io）有什么区别？在一些研究中，我只能得出这样的结论：GitLab社区版不允许添加Jenkins，但是GitLab企业版可以。还有其他重大区别吗？
Answers:
这是我的经验：
在我的工作中，我们使用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还通过Jenkinsfile和pipline插件自Jenkins 2起默认支持更多的“适当的ci” ），但与GitLab CI相比，它与存储库的耦合较少。
使用YAML文件定义您的构建管道（最终运行纯shell / bat）更为简洁。
Jenkins可用的插件使您可以可视化各种报告，例如测试结果，覆盖率和其他静态分析仪。当然，您始终可以编写或使用工具来为您完成此操作，但这绝对对詹金斯（尤其是对于倾向于对这些报告过于看重的经理们）来说是一个加分项。
最近，我与GitLab CI的合作越来越多。在GitLab，他们做得非常出色，使整个体验变得有趣。我知道人们会使用Jenkins，但是当您运行并启用了GitLab时，开始使用GitLab CI真的很容易。即使它们在第三方集成上花费了很多精力，也不会有任何东西可以像GitLab CI那样无缝集成。
撰写本文时有一些好处：
我同意Rik的大部分笔记，但我对哪种更简单的看法却相反：GitLab被证明是一个很棒的工具。
大部分功能来自于设备齐全，并将所有内容集成到同一产品的同一浏览器选项卡下：从存储库浏览器，发行板或构建历史到部署工具和监视。
我现在正在使用它来自动化和测试应用程序如何在不同的Linux发行版上进行安装，并且配置速度非常快（尝试在Firefox中打开复杂的Jenkins作业配置，并等待无响应脚本与。编辑的轻巧程度.gitlab-ci.yml）。
得益于运行程序二进制文件，在配置/扩展从站上花费的时间大大减少了；再加上在GitLab.com上您获得了相当不错的免费共享跑步者。
在成为GitLab CI的高级用户后，Jenkins感到更加手动，例如，每个分支重复工作，安装插件以执行诸如SCP上传之类的简单操作。到目前为止，我所面对的唯一用例是涉及多个存储库。还需要很好地弄清楚。
顺便说一句，我目前正在编写有关GitLab CI的系列文章，以演示如何使用它配置存储库CI基础架构并不难。上周发布的第一篇文章介绍了其他工具的基础，优缺点以及与众不同：与GitLab CI进行快速自然的持续集成
Jenkinsfile。没错，您Jenkinsfile可以使用常规代码（+其他Java库）来运行代码，该.gitlab-ci.yaml文件主要支持shell，但是（取决于运行程序的位置）。另一方面，您也可以从shell脚本中调用所有这些命令，但是缺点是您正在创建机器依赖项（我认为这不是很透明）。
首先，从今天开始，GitLab社区版可以与Jenkins完全互操作。没有问题。
在下文中，我对结合Jenkins和GitLab CI的成功经验提供了一些反馈。我还将讨论您是应该同时使用还是两者都使用，以及出于什么原因。
我希望这将为您提供有关自己项目的质量信息。
亚搏体育app CI
GitLab CI自然地集成在GitLab SCM中。您可以使用gitlab-ci.yml文件创建管道，并通过图形界面对其进行操作。
这些作为代码的管道显然可以存储在代码库中，从而加强“一切都作为代码”实践（访问，版本控制，可再现性，可重用性等）。
GitLab CI是出色的可视化管理工具：
詹金斯
Jenkins是一个很棒的构建工具。它的优势在于其许多插件。特别是，我在Jenkins与其他CI或CD工具之间使用接口插件感到非常幸运。与重新开发（可能很糟）两个组件之间的对话框界面相比，这总是一个更好的选择。
也可以使用groovy脚本将流水线作为代码。
起初听起来可能有点多余，但是将GitLab CI和Jenkins结合起来是非常强大的。
这种设计的另一个好处是工具之间的连接松散：
好吧，当然，要为此设计付出代价：初始设置很麻烦，并且您需要对许多工具有最少的了解。
因此，我不建议您进行此类设置，除非
如果您都不处于这两种情况下，则最好只使用两者中的一种，而不是两者兼而有之。
GitLab CI和Jenkins都有优点和缺点。两者都是强大的工具。那么选择哪一个呢？
答案1
选择您的团队（或亲密的人）已经具备一定专业知识的团队。
答案2
如果您都是CI技术的新生，那么只需选择其中一个就可以开始。
那些正在使用GitLab并不确定会继续这样做的人仍然必须记住，选择GitLab CI意味着将破坏您的所有CI / CD管道。
最后一句话是：天平倾斜一点点，因为它的许多插件对詹金斯位，但机会是GitLab CI将迅速填补了国内空白。
我想补充一下我最近在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"
我非常喜欢GitLab CI！是的，到目前为止（它）无法绘制具有覆盖率的漂亮图形，等等，但总体而言，这是一个非常整洁的工具！
编辑（2019-02-23）： 这是我关于 GitLab CI中我喜欢的东西的文章。它是用11.7“时代”编写的，因此当您阅读此答案时，GitLab CI可能具有更多功能。
编辑（2019-07-10）： Gitlab CI现在支持多个extends例如
extends:
- .pieceA
- .pieceB
查看官方文档以获取有关多个扩展的更多信息
如果您的构建/发布/部署和测试工作不是很复杂，那么使用gitlab ci具有自然的优势。
由于gitlab-ci.yml在每个分支中都与代码一起出现，因此您可以更有效地修改ci / cd步骤，尤其是测试（在不同环境中有所不同）。
例如，您想对dev分支的任何签入进行单元测试，而您可能想在QA分支上进行完整的功能测试，并且在生产中进行有限的仅get类型的测试，这可以使用gitlab ci轻松实现。
除了出色的UI外，第二个优势是它可以使用docker映像执行任何阶段的功能，使主机运行程序保持完整，从而减少出错的可能性。
而且gitlab ci会自动为您签入，您不必单独管理jenkins master