PROSAGA码农传奇-jenkins-Gitlab CI vs Jenkins

0# 哎？小查查 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”>
  
    首先，截至今天，Gitlab Community Edition可以与Jenkins完全互操作。没有问题。
  
  
    接下来，我将结合Jenkins和gitlab-ci的成功经验给出一些反馈。我还将讨论你是应该同时使用它们还是仅使用其中一种，以及出于什么原因。
  
  
    我希望这能为您提供有关您自己项目的高质量信息。
  
  <H3>
    GitLab-CI和Jenkins的优势
  </H3>
  
    的
      GitLab-CI
    </强>
  
  
     <code>
 gitlab-ci
 </code>
     自然地集成在Gitlab SCM中。您可以使用创建管道
     <code>
 gitlab-ci.yml
 </code>
     文件并通过图形界面操纵它们。
  
  
    这些代码管道显然可以存储在代码库中，强制执行“一切代码”实践（访问，版本控制，可重复性，可重用性......）。
  
  
     <code>
 gitlab-ci
 </code>
     是一个很棒的视觉管理工具：
  
  <UL>
    <LI>
      所有团队成员（包括非技术团队成员）都可以快速轻松地访问应用程序生命周期状态。
    </LI>
    <LI>
      因此它可以用作
      
        互动
      
       和
      
        操作
      
       用于发布管理的仪表板。
    </LI>
  </UL>
  
    的
      詹金斯
    </强>
  
  
    Jenkins是一个很棒的构建工具。它的优势在于它的众多插件。特别是，我很幸运在Jenkins和其他CI或CD工具之间使用接口插件。这总是比重新开发（可能很糟糕）两个组件之间的对话界面更好的选择。
  
  
    管道作为代码也可以使用
     <code>
 groovy
 </code>
    脚本。
  
  <H3>
    一起使用GitLab-CI和Jenkins
  </H3>
  
    起初听起来有点多余，但是将gitlab-ci和Jenkins结合起来非常强大。
  
  <UL>
    <LI>
      GitLab-CI协调（链，运行，监视...）管道，并且可以将其集成到Gitlab的图形界面受益
    </LI>
    <LI>
      Jenkins负责这项工作并促进与第三方工具的对话。
    </LI>
  </UL>
  
    这种设计的另一个好处是在工具之间失去耦合：
  
  <UL>
    <LI>
      我们可以替换任何构建工厂组件，而无需重做整个CI / CD过程
    </LI>
    <LI>
      我们可以拥有一个异构的构建环境，组合（可能是几个）Jenkins，Team City，你可以命名它，并且仍然只有一个监控工具。
    </LI>
  </UL>
  <H3>
    权衡
  </H3>
  
    嗯，当然，这个设计需要付出代价：初始设置很麻烦，你需要对许多工具有一个最低限度的理解。
  
  
    因此，我建议不要这样设置
  
  <UL>
    <LI>
      你有很多第三方工具可以处理。就在那时，Jenkins带来了很多插件，非常方便。
    </LI>
    <LI>
      您必须使用异构技术处理复杂的应用程序，使每个应用程序具有不同的构建环境，并且仍然需要具有统一的应用程序生命周期管理UI。
    </LI>
  </UL>
  
    如果你不处于这两种情况中，那么你最好只选择其中一种，但不能两者兼而有之。
  
  <H3>
    如果我不得不选一个
  </H3>
  
    都
     <code>
 gitlab-ci
 </code>
     和詹金斯有利有弊。两者都是强大的工具。那么选择哪一个？
  
  
    的
      答案1
    </强>
  
  
    选择您的团队（或某人关闭）已经达到某个级别的团队
专业知识。
  
  
    的
      答案2
    </强>
  
  
    如果你们都是CI技术的新手，那就选择一个然后开始吧。
  
  <UL>
    <LI>
      如果你正在使用Gitlab并且对代码的所有东西都有诀窍，那么选择它就会让人感觉完全敏感
       <code>
 gitlab-ci
 </code>
      。
    </LI>
    <LI>
      如果您必须与许多其他CI / CD工具对话或者绝对需要GUI来构建您的工作，请转到Jenkins。
    </LI>
  </UL>
  
    那些使用Gitlab且不确定他们会继续这样做的人仍然要记住，选择了
     <code>
 gitlab-ci
 </code>
     意味着要删除所有CI / CD管道。
  
  
    最后一句话是：平衡倾向于
    
      小
    
     由于它有很多插件，所以对Jenkins有点不同，但很有可能
     <code>
 gitlab-ci
 </code>
     将很快填补空白。
  
</DIV>

1# 冷月如霜·胡狼 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”>
  
    我想补充一下我最近试验Gitlab CI的一些发现。
11.6和11.7附带的功能真棒！
  
  
    我特别喜欢
     <code>
 only
 </code>
     基本上允许您为其构建单独管道的条件
     <code>
 merge_request
 </code>
     要么
     <code>
 push
 </code>
     （完整的清单是
    <a href="https://docs.gitlab.com/ee/ci/yaml/#only-and-except-complex" rel="nofollow noreferrer">
      这里
    </A>
    ）
  
  
    另外，我真的很喜欢没有插件。当我需要一些更复杂的功能时，我只需编写处理所需功能的自定义Docker镜像（它与您在其中看到的概念相同）
    <a href="https://docs.drone.io/plugins/examples/bash/" rel="nofollow noreferrer">
      drone.io
    </A>
    ）
  
  
    如果你想知道DRY，现在绝对可能！你可以写下你的“模板”
  
   <pre>
 <code>
 .myTemplate:
 image: node:10.14.2
 script:
 - npm install
 - npm run test

</code>
 </pre>
  
    将它们放到一些公共存储库中，将它们包含在主要管道中
  
   <pre>
 <code>
 include:
 - remote: https://....

</code>
 </pre>
  
    并用它们来扩展一些工作
  
   <pre>
 <code>
 test:
 extends: .myTemplate
 only:
 refs: ["master"]
 variables:
 - $CI_PIPELINE_SOURCE == "push"

</code>
 </pre>
  
    的
      我非常喜欢Gitlab CI！
    </强>
     是的，它（到目前为止）不能用覆盖等绘制漂亮的图形，但总的来说它是非常简洁的工具！
  
  
    的
      编辑（02/23/2019）：
    </强>
    <a href="https://www.ackee.cz/blog/en/experimenting-with-gitlab-ci/" rel="nofollow noreferrer">
      这是我的帖子
    </A>
     在Gitlab CI中我喜欢的东西。它是在11.7“时代”写的，所以当你读到这个答案时，Gitlab CI可能有更多的功能。
  
</DIV>

2# 一瓶泡沫 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”>
  
    我同意Rik的大部分笔记，但我对哪个更简单的看法是
    的
      相反的
    </强>
    ：GitLab被证明是一个很棒的工具。
  
  
    大部分力量来自存在
    的
      自足
    </强>
     和
    <a href="https://about.gitlab.com/direction/#scope" rel="noreferrer">
      整合一切
    </A>
     在同一浏览器选项卡下的同一产品中：从存储库浏览器，发行板或构建历史记录到部署工具和
    <a href="https://about.gitlab.com/2017/01/05/prometheus-and-gitlab/" rel="noreferrer">
      监控
    </A>
    。
  
  
    我现在正在使用它来自动化和测试应用程序如何安装在不同的Linux发行版上而且它只是
    的
      快速配置
    </强>
     （尝试在firefox上打开复杂的Jenkins作业配置，等待无响应的脚本出现与编辑轻量级的对比
     <code>
 .gitlab-ci.yml
 </code>
    ）。由于这个原因，配置/调度奴隶所花费的时间要少得多
    <a href="https://docs.gitlab.com/runner/install" rel="noreferrer">
      亚军双打
    </A>
    ;再加上这个事实
    <a href="http://gitlab.com" rel="noreferrer">
      GitLab.com
    </A>
     你得到相当体面和免费的共享跑步者。
  
  
    詹金斯觉得
    
      更多手册
    
     在成为GitLab CI的高级用户几周后，例如，每个分支复制作业，安装插件以执行简单的操作，例如SCP上传。我遇到的唯一一个用例，就像我今天所想的那样，当涉及多个存储库时;这需要很好地解决。
  
  
    顺便说一句，我现在正在写一篇关于GitLab CI的系列文章来演示如何用它来配置你的存储库CI基础设施并不困难。上周发表的第一篇文章介绍了其他工具的基础知识，优缺点和差异：
    <a href="https://solidgeargroup.com/gitlab_countinuous_integration_intro" rel="noreferrer">
      https://solidgeargroup.com/gitlab_countinuous_integration_intro
    </A>
  
</DIV>

3# 至此 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”>
  
    这是我的经历：
  
  
    在我的工作中，我们使用gitlab ee管理我们的存储库，并且我们运行了Jenkins服务器（1.6）。
  
  
    在他们的基础上他们几乎一样。他们将在服务器/ docker镜像上运行一些脚本。
  
  
    的
      TL; DR;
    </强>
  
  <UL>
    <LI>
      詹金斯更容易使用/学习，但有可能成为一个插件地狱
    </LI>
    <LI>
      Jenkins有一个GUI（如果必须可由其他人访问/维护，这可能是首选）
    </LI>
    <LI>
      与GitLab的集成比使用Gitlab-ci要少
    </LI>
    <LI>
      詹金斯可以拆分你的回购
    </LI>
  </UL>
  
    大多数CI服务器非常直接（
    <a href="https://concourse-ci.org/" rel="noreferrer">
      concourse.ci
    </A>
    ，
    <a href="http://docs.gitlab.com/ce/ci/quick_start/" rel="noreferrer">
      gitlab慈
    </A>
    ，
    <a href="https://circleci.com/" rel="noreferrer">
      圆慈
    </A>
    ，
    <a href="https://travis-ci.org/" rel="noreferrer">
      特拉维斯慈
    </A>
    ，
    <a href="https://drone.io/" rel="noreferrer">
      drone.io
    </A>
    ，
    <a href="https://www.gocd.org/" rel="noreferrer">
      gocd
    </A>
     你还有什么呢？它们允许您从yaml文件定义执行shell / bat。 Jenkins更加可插拔，并带有UI。根据您的需要，这可能是优势或劣势。
  
  
    由于可用的所有插件，Jenkins非常易于配置。这样做的缺点是您的CI服务器可能成为插件的意义。
  
  
    在我看来，在Jenkins中链接和编排作业要比通过Yaml（调用curl命令）简单得多（因为UI）。除此之外，Jenkins支持在服务器上不可用时安装某些二进制文件的插件（不知道其他二进制文件）。
  
  
    如今（
    <a href="http://jenkins-ci.org/2.0" rel="noreferrer">
      jenkins2
    </A>
     也支持更多“适当的ci”
     <code>
 Jenkinsfile
 </code>
     和
    <a href="https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin" rel="noreferrer">
      pipline
    </A>
     默认情况下来自Jenkins 2）的插件，但是比gitlab ci更少耦合到存储库。
  
  
    使用yaml文件来定义构建管道（最后运行纯shell / bat）更清晰。
  
  
    的
      编辑：
    </强>
     我忘记在这里提到的是Jenkins可用的插件，它允许您可视化各种报告，例如测试结果，覆盖范围和其他静态分析器。当然，您总是可以编写或使用工具为您执行此操作，但对Jenkins来说绝对是一个优势（特别是对于那些倾向于过多评估这些报告的经理而言）
  
  
    的
      EDIT2：
    </强>
     最近我和Gitlab-ci一起工作越来越多。在Gitlab，他们做得非常出色，让整个体验充满乐趣。我知道人们使用Jenkins，但是当你运行Gitlab并且可用时，很容易开始使用Gitlab-ci。即使他们在第三方集成中付出了相当大的努力，也不会像Gitlab-ci那样无缝集成任何东西。
  
  <UL>
    <LI>
      他们的文档应该让你立刻开始
    </LI>
    <LI>
      入门的门槛非常低
    </LI>
    <LI>
      维护很简单（没有插件）
    </LI>
    <LI>
      缩放跑步者很简单
    </LI>
    <LI>
      CI完全属于您的存储库
    </LI>
    <LI>
      詹金斯的工作/观点可能会变得混乱
    </LI>
  </UL>
  
    写作时的一些好处
  
  <UL>
    <LI>
      仅支持单个文件，但这将是
      <a href="https://gitlab.com/gitlab-org/gitlab-ce/issues/20868" rel="noreferrer">
        固定
      </A>
       不久
    </LI>
  </UL>
</DIV>