git GitLab CI 与 Jenkins

GitLab CI vs. Jenkins

提问by Ravikiran butti

What is the difference between Jenkins and other CI like GitLab CI, drone.io coming with the Git distribution. On some research I could only come up that GitLab community edition doesn't allow Jenkins to be added, but GitLab enterprise edition does. Are there any other significant differences?

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

采纳答案by Rik

This is my experience:

这是我的经验：

At my work we manage our repositories with GitLab EE and we have a Jenkins server (1.6) running.

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

In the basis they do pretty much the same. They will run some scripts on a server/Docker image.

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

TL;DR;

TL; 博士;

• Jenkins is easier to use/learn, but it has the risk to become a plugin hell
• Jenkins has a GUI (this can be preferred if it has to be accessible/maintainable by other people)
• Integration with GitLab is less than with GitLab CI
• Jenkins can be split off your repository

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

Most CI servers are pretty straight forward (concourse.ci), gitlab-ci, circle-ci, travis-ci, drone.io, gocdand what else have you). They allow you to execute shell/bat scripts from a YAML file definition. Jenkins is much more pluggable, and comes with a UI. This can be either an advantage or disadvantage, depending on your needs.

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

Jenkins is very configurable because of all the plugins that are available. The downside of this is that your CI server can become a spaghetti of plugins.

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

In my opinion chaining and orchestrating of jobs in Jenkins is much simpler (because of the UI) than via YAML (calling curl commands). Besides that Jenkins supports plugins that will install certain binaries when they are not available on your server (don't know about that for the others).

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

Nowadays (Jenkins 2also supports more "proper ci" with the Jenkinsfileand the piplineplugin which comes default as from Jenkins 2), but used to be less coupled to the repository than i.e. GitLab CI.

如今（Jenkins 2还支持更多“适当的 ci”Jenkinsfile和Jenkins 2 中默认的pipline插件），但过去与 GitLab CI 相比，与存储库的耦合更少。

Using YAML files to define your build pipeline (and in the end running pure shell/bat) is cleaner.

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

The plug-ins available for Jenkins allow you to visualize all kinds of reporting, such as test results, coverage and other static analyzers. Of course, you can always write or use a tool to do this for you, but it is definitely a plus for Jenkins (especially for managers who tend to value these reports too much).

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

Lately I have been working more and more with GitLab CI. At GitLab they are doing a really great job making the whole experience fun. I understand that people use Jenkins, but when you have GitLab running and available it is really easy to get started with GitLab CI. There won't be anything that will integrate as seamlessly as GitLab CI, even though they put quite some effort in third-party integrations.

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

• Their documentation should get you started in no time.
• The threshold to get started is very low.
• Maintenance is easy (no plugins).
• Scaling runners is simple.
• CI fully part of your repository.
• Jenkins jobs/views can get messy.

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

Some perks at the time of writing:

撰写本文时的一些福利：

• Only support for a single file in the community edition. Multiples files in the enterprise edition.

• 社区版仅支持单个文件。企业版中的多个文件。

回答by Alfageme

I agree with most of Rik's notes, but my opinion about which is a simpler is the opposite: GitLab is proving to be an awesome tool to work with.

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

Most of the power comes from being self-containedand integrating everythingin the same product under the same browser tab: from repository browser, issue board or build history to deployment tools and monitoring.

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

I'm using it right now to automate and test how an application installs on different Linux distributions, and it's just blazing fast to configure(try to open a complex Jenkins job configuration in Firefox and wait for the non-responsive script to come up vs. how lightweight is to edit .gitlab-ci.yml).

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

The time spent on configuring/scaling slaves is considerably less thanks to the runner binaries; plus the fact that in GitLab.comyou get quite decent and free shared runners.

由于运行器二进制文件，配置/扩展从属设备所花费的时间大大减少；再加上在GitLab.com 中，您可以获得相当不错的免费共享跑步者。

Jenkins feels more manualafter some weeks of being a power user of GitLab CI, e.g. duplicating jobs per branch, installing plugins to do simple stuff such as SCP upload. The only use-case I have faced where I miss it as for today is when more than one repository is involved; that needs to be nicely figured out yet.

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

BTW, I'm currently writing a series on GitLab CI to demonstrate how it's not that hard to configure your repository CI infrastructure with it. Published last week, the first piece is introducing the basics, pros and cons and differences with other tools: Fast and natural Continuous Integration with GitLab CI

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

回答by avi.elkharrat

First of all, as of today, GitLab Community Edition can be fully interoperable with Jenkins. No question.

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

In what follows, I give some feedback on a successful experience combining both Jenkins and GitLab CI. I shall also discuss whether you should use both or only one of them, and for what reason.

接下来，我就结合 Jenkins 和 GitLab CI 的成功经验给出了一些反馈。我还将讨论您是应该使用两者还是只使用其中之一，以及出于什么原因。

I hope this will give you quality information on your own projects.

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

GitLab CI and Jenkins strengths

GitLab CI 和 Jenkins 的优势

GitLab CI

亚搏体育app CI

GitLab CI is naturally integrated in GitLab SCM. You can create pipelines using gitlab-ci.ymlfiles and manipulate them through a graphical interface.

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

These pipelines as code can obviously be stored in the code base, enforcing the "everything as code" practice (access, versioning, reproducibility, reusability, etc.).

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

GitLab CI is a great visual management tool:

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

• all members of the teams (including the non-technical ones) have quick and easy access to applications life cycle status.
• therefore it can be used as a interactiveand operationaldashboard for release management.

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

Jenkins

詹金斯

Jenkins is a great build tool. It's strength is in its many plugins. Especially, I've had great luck in using interface plugins between Jenkins and other CI or CD tools. This is always a better option than to redevelop (possibly badly) a dialog interface between two components.

Jenkins 是一个很棒的构建工具。它的优势在于它的许多插件。特别是，我在 Jenkins 和其他 CI 或 CD 工具之间使用接口插件非常幸运。这总是比重新开发（可能很糟糕）两个组件之间的对话界面更好的选择。

Pipeline as code is also available using groovyscripts.

管道即代码也可以使用groovy脚本使用。

Using GitLab CI and Jenkins together

一起使用 GitLab CI 和 Jenkins

It might sound a bit redundant at first, but combining GitLab CI and Jenkins is quite powerful.

乍一看可能有点多余，但结合 GitLab CI 和 Jenkins 是非常强大的。

• GitLab CI orchestrates (chains, runs, monitors...) pipelines and one can benefit its graphical interface integrated to GitLab
• Jenkins runs the job and facilitates dialog with third-party tools.

• GitLab CI 编排（链、运行、监控...）管道，并且可以受益于其集成到 GitLab 的图形界面
• Jenkins 运行作业并促进与第三方工具的对话。

Another benefit of this design is to have loose coupling between the tools:

这种设计的另一个好处是工具之间的松散耦合：

• we could replace any of the build factory components without having to rework the entire CI/CD process
• we could have a heterogeneous build environment, combining (possibly several) Jenkins, TeamCity, you name it, and still have a single monitoring tool.

• 我们可以替换任何构建工厂组件，而无需返工整个 CI/CD 流程
• 我们可以拥有一个异构的构建环境，结合（可能有几个）Jenkins、TeamCity 等等，并且仍然有一个单一的监控工具。

The Trade-off

权衡

Well, of course, there is a price to pay for this design: the initial set-up is cumbersome and you need to have a minimal level of understanding of many tools.

嗯，当然，这种设计是要付出代价的：初始设置很麻烦，而且您需要对许多工具有最低限度的了解。

For this reason, I don't recommend such a set-up unless

出于这个原因，我不推荐这样的设置，除非

• you have many third-party tools to deal with. That's when Jenkins comes in super handy with its many plugins.
• you have to deal with complex applications with heterogeneous technologies, having each a different build environment, and still need to have a unified application life cycle management UI.

• 您有许多第三方工具需要处理。这就是 Jenkins 凭借其众多插件变得非常方便的时候。
• 您必须处理具有异构技术的复杂应用程序，每个应用程序都有不同的构建环境，并且仍然需要有一个统一的应用程序生命周期管理 UI。

If you are in neither of these situations, you're probably better off with only one of the two, but not both.

如果您不属于这两种情况，那么您可能只使用这两种情况中的一种会更好，但不能同时使用两者。

If I had to pick one

如果我必须选择一个

Both GitLab CI and Jenkins have pros and cons. Both are powerful tools. So which one to choose?

GitLab CI 和 Jenkins 各有利弊。两者都是强大的工具。那么该选择哪一个呢？

Answer 1

答案 1

Choose the one that your team (or someone close) has already a certain level of expertise in.

选择您的团队（或亲近的人）已经具备一定专业知识水平的团队。

Answer 2

答案 2

If you're all complete freshman in CI technologies, just pick one and get going.

如果你们都是 CI 技术的大一新生，那就选一个然后开始吧。

• If you're using GitLab and have a knack for everything as code, it makes total sens to choose GitLab CI.
• If you have to dialog with many other CI/CD tools or absolutely need that GUI to build your jobs, go for Jenkins.

• 如果您正在使用 GitLab 并且对所有内容都精通代码，那么选择 GitLab CI 是完全明智的。
• 如果您必须与许多其他 CI/CD 工具进行对话，或者绝对需要该 GUI 来构建您的作业，请选择 Jenkins。

Those of you that are using GitLab and are not sure they will keep doing so still have to keep in mind that, having chosen GitLab CI would imply to trash all your CI / CD pipelines.

那些正在使用 GitLab 并且不确定他们是否会继续使用的人仍然必须记住，选择 GitLab CI 意味着丢弃您所有的 CI / CD 管道。

Final word is: the balance leans a littlebit towards Jenkins because of its many plugins, but chances are GitLab CI will quickly fill the gap.

最后一句话是：天平倾斜一点点，因为它的许多插件对詹金斯位，但机会是GitLab CI将迅速填补了国内空白。

回答by Stepan Vrany

I would like to add some findings from my recent experimenting with GitLab CI. Features that came with 11.6 and 11.7 are just awesome!

我想从我最近对 ​​GitLab CI 进行的实验中添加一些发现。11.6 和 11.7 附带的功能非常棒！

Specifically I love onlyconditions which basically allow you to build separate pipelines for merge_requestor push(the complete list is here)

具体来说，我喜欢only基本上允许您为merge_requestor构建单独管道的条件push（完整列表在这里）

Also, I really like the absence of plugins. When I need some more complex functionality I just write a custom Docker image that handles required functionality (it's the same concept as you can see in drone.io).

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

If you are wondering about DRY, it's absolutely possible nowadays! You can write your "templates,"

如果您想知道DRY，现在绝对有可能！你可以写你的“模板”，

.myTemplate:
  image: node:10.14.2
  script:
    - npm install
    - npm run test

Put them to some public repository, include them in the main pipeline:

将它们放入某个公共存储库，将它们包含在主管道中：

include:
  - remote: https://....

And use them to extend some job:

并使用它们来扩展一些工作：

test:
  extends: .myTemplate
  only:
    refs: ["master"]
    variables:
      - $CI_PIPELINE_SOURCE == "push"

I love GitLab CI so much!Yeah, it (so far) can't draw nice graphs with coverage and so on, but overall it's a really neat tool!

我非常喜欢 GitLab CI！是的，它（到目前为止）无法绘制包含覆盖范围等的漂亮图表，但总体而言，它是一个非常简洁的工具！

Edit (2019-02-23):here's my post aboutthings I love in GitLab CI. It was written in 11.7 "era" so when you're reading this answer, GitLab CI probably has many more features.

编辑 (2019-02-23)：这是我在 GitLab CI 中关于我喜欢的东西的帖子。它是在 11.7"era" 中编写的，因此当您阅读此答案时，GitLab CI 可能具有更多功能。

Edit (2019-07-10):Gitlab CI now supports multiple extendse.g.

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

extends:
 - .pieceA
 - .pieceB

Check the official documentation to get more info about multiple extends

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

回答by Rajanikant Patel

if your build/publish/deploy and test jobs are not heavily complex then using gitlab ci has natural advantages.

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

Since gitlab-ci.yml is present alongside your code in every branch, you can modify your ci/cd steps particularly tests(which differs across environments) more effectively.

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

For an example, you want to do unit testing for any checkin to dev branch whereas you might want carry out full fledged functional testing on QA branch and a limited only get type of tests on production this can be achieved easily using gitlab ci.

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

second advantage apart from great UI is its ability to use docker images for executing any stage keeps the host runner intact and thus less error prone.

除了出色的 UI 之外，第二个优势是它能够使用 docker 图像来执行任何阶段，从而使主机运行器保持完整，从而减少出错的可能性。

moreover gitlab ci would automatically checkin for you and you dont have to manage jenkins master separately

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