CI do GitLab vs. Jenkins [fechado]


129

Qual é a diferença entre Jenkins e outro IC, como o GitLab CI, drone.io, que vem com a distribuição Git. Em algumas pesquisas, só pude descobrir que a edição da comunidade GitLab não permite a adição de Jenkins, mas a edição corporativa do GitLab permite. Existem outras diferenças significativas?


5
Gitlab também agora montar uma comparação de gitlab CI vs Jenkins: about.gitlab.com/comparison/gitlab-vs-jenkins.html
bbodenmiller

Respostas:


122

Esta é a minha experiência:

No meu trabalho, gerenciamos nossos repositórios com o GitLab EE e temos um servidor Jenkins (1.6) em execução.

Na base, eles fazem praticamente o mesmo. Eles executarão alguns scripts em uma imagem de servidor / Docker.

TL; DR;

  • Jenkins é mais fácil de usar / aprender, mas corre o risco de se tornar um inferno de plugins
  • Jenkins tem uma GUI (isso pode ser preferido se precisar ser acessível / sustentável por outras pessoas)
  • A integração com o GitLab é menor do que com o IC do GitLab
  • Jenkins pode ser separado do seu repositório

A maioria dos servidores de CI é bastante direta ( concourse.ci ), gitlab-ci , circle-ci , travis-ci , drone.io , gocd e o que mais você tem. Eles permitem executar scripts shell / bat a partir de uma definição de arquivo YAML. Jenkins é muito mais conectável e vem com uma interface do usuário. Isso pode ser uma vantagem ou uma desvantagem, dependendo de suas necessidades.

Jenkins é muito configurável por causa de todos os plugins disponíveis. A desvantagem disso é que seu servidor de IC pode se tornar um espaguete de plugins.

Na minha opinião, encadear e orquestrar trabalhos em Jenkins é muito mais simples (por causa da interface do usuário) do que via YAML (chamando comandos curl). Além disso, o Jenkins suporta plugins que instalam certos binários quando eles não estão disponíveis no seu servidor (não sabemos disso para os outros).

Atualmente (o Jenkins 2 também suporta mais "ci adequado" com o plug- in Jenkinsfilee o pipline, que vem por padrão a partir do Jenkins 2), mas costumava ser menos acoplado ao repositório do que o CI do GitLab.

O uso de arquivos YAML para definir seu pipeline de construção (e, no final, executar shell / bat puro) é mais limpo.

Os plug-ins disponíveis para o Jenkins permitem visualizar todos os tipos de relatórios, como resultados de testes, cobertura e outros analisadores estáticos. Obviamente, você sempre pode escrever ou usar uma ferramenta para fazer isso por você, mas é definitivamente uma vantagem para Jenkins (especialmente para gerentes que tendem a valorizar muito esses relatórios).

Ultimamente, tenho trabalhado cada vez mais com o GitLab CI. No GitLab, eles estão fazendo um ótimo trabalho, tornando toda a experiência divertida. Entendo que as pessoas usam o Jenkins, mas quando você tem o GitLab em execução e está disponível, é realmente fácil começar a usar o GitLab CI. Não haverá nada que se integre tão perfeitamente quanto o GitLab CI, mesmo que eles se esforcem bastante nas integrações de terceiros.

  • A documentação deles deve começar rapidamente.
  • O limite para começar é muito baixo.
  • A manutenção é fácil (sem plugins).
  • Escalar os corredores é simples.
  • O CI faz parte totalmente do seu repositório.
  • Os trabalhos / visualizações Jenkins podem ficar confusos.

Algumas vantagens no momento da escrita:

  • Suporte apenas para um único arquivo na edição da comunidade. Múltiplos arquivos na edição corporativa .

13
Jenkins podem agora obter um agradável GUI graças ao Oceano Azul
Ayoub Kaanich

3
A partir do gitlab 9.3, o suporte ao pipeline de multiprojetos é adicionado. Essa foi para mim uma das principais razões para manter Jenkins. Atualmente, estou fazendo um PoC para verificar se posso gerenciar com o gitlab, pois eles claramente também estão focados nisso agora e estão evoluindo muito mais rapidamente. Além disso, eu realmente amo a interface do usuário e como ela evoluiu ao longo do tempo.
Rik

4
O melhor dos arquivos yaml é que você documenta suas alterações no pipeline diretamente onde deveria estar .. no repositório como parte do código-fonte. Assim, você pode ter ramificações com diferentes arquivos yaml para diferentes ramificações de lançamento. Claro, a fusão do yaml pode ser uma bagunça :) A criação de imagens mesclando dois piplelines em jenkins é um trabalho muito mais difícil.
Christian Müller

O jenkins fornece muito mais ferramentas do que o gitlab ci. gitlab / jenkins Juntos, a integração é possível e é realmente transparente para o usuário, se bem configurada. juntar dois piplelines no jenkins é fácil com o Jenkinsfile em seu repositório ... você precisará de plugins de ramificação de origem gitlab e gitlab
sancelot

1
O que significa "Suporte apenas a um único arquivo na edição da comunidade. Múltiplos arquivos na edição corporativa". ? Desculpe, tentei ler o problema em anexo, mas não consegui identificar.
Lester

62

Concordo com a maioria das anotações de Rik, mas minha opinião sobre o que é mais simples é o oposto : o GitLab está provando ser uma ferramenta incrível de se trabalhar.

A maior parte do poder vem de ser independente e integrar tudo no mesmo produto na mesma guia do navegador: do navegador do repositório, do quadro de problemas ou do histórico de construção às ferramentas e monitoramento de implantação .

Estou usando agora para automatizar e testar como um aplicativo é instalado em diferentes distribuições Linux, e é rápido demais para configurar (tente abrir uma configuração complexa de tarefas Jenkins no Firefox e aguarde o script não responsivo aparecer vs quão leve é ​​a edição .gitlab-ci.yml).

O tempo gasto na configuração / dimensionamento de escravos é consideravelmente menor graças aos binários dos corredores ; além do fato de que no GitLab.com você obtém corredores compartilhados bastante decentes e gratuitos.

Jenkins se sente mais manual depois de algumas semanas sendo um usuário avançado do GitLab CI, por exemplo, duplicando trabalhos por filial, instalando plugins para fazer coisas simples, como o upload de SCP. O único caso de uso que enfrentei onde sinto falta hoje é quando mais de um repositório está envolvido; que ainda precisa ser bem resolvido.

No momento, estou escrevendo uma série no IC do GitLab para demonstrar como não é tão difícil configurar sua infraestrutura de CI de repositório com ele. Publicado na semana passada, o primeiro artigo apresenta os princípios, prós e contras e as diferenças com outras ferramentas: Integração contínua rápida e natural com o GitLab CI


5
Eu concordo totalmente com você sobre o Gitlab. No momento em que escrevi, o gitlab não estava tão completo quanto é hoje em dia. Eu gosto muito do Gitlab como uma ferramenta e realmente aprecio todo o trabalho que eles estão colocando nele.
Rik

1
@alfageme: Vou verificar seus Relatórios no site mencionado De qualquer forma: Obrigado por todas as suas explicações. Neste exato momento, vou decidir se usamos o gitlabCI ou o Jenkins para o nosso material de CI.
Max Schindler

3
@Rik Eu gosto do IC do Gitlab, no entanto, ouço argumentos do outro lado dizendo que é difícil manter arquivos yaml porque não há possibilidade de reutilização porque muitos dos arquivos yaml em um pipeline seguem a mesma estrutura e o Templating não é visto como uma opção superior ao jenkinsfile porque jenkinsfile usa groovy. portanto, trata-se de código versus configuração para reutilização. você pode compartilhar seus pensamentos sobre isso?
precisa saber é o seguinte

1
@ user1870400 Não sei bem o que você quer dizer com modelagem. Porque, tanto quanto eu posso ver, é apenas um arquivo no seu repositório. E isso não é diferente em comparação com o seu Jenkinsfile. Você está certo de que Jenkinsfilepossui groovy (+ java libs adicionais) disponíveis para executar código, onde o .gitlab-ci.yamlarquivo suporta principalmente shell, mas (dependendo da localização do runner). Por outro lado, você também pode chamar isso de um script de shell, mas a desvantagem é que você está criando dependências de máquina (que na minha opinião não são muito transparentes).
Rik

1
@Alfageme - Comecei a usar o Gitlab CI também e me afastei do Jenkins. Uso-o em instantes para compilação automática, upload para o Nexus, implantação no ambiente DEV e execução de testes de unidade. Essa sequência é executada no nível do projeto (padrão). Após o DEV, também preciso gerenciar a implantação de vários projetos (grupo Gitlab). Criei a GUI que usa APIs do Gitlab, Nexus etc. onde você seleciona o TAG mais recente do projeto para implantar e as tags mais recentes dos projetos em grupo também são implantadas (ingênuas). Eu trabalho na extensão para suportar a definição da matriz de versão (o projec1v1.1 é compatível com o projeto2v3.2), vou apresentar uma solicitação de recurso no gitlab para isso.
Kensai #

22

Antes de tudo, a partir de hoje, o GitLab Community Edition pode ser totalmente interoperável com o Jenkins. Nenhuma pergunta.

A seguir, dou alguns comentários sobre uma experiência bem-sucedida combinando o Jenkins e o GitLab CI. Também discutirei se você deve usar os dois ou apenas um deles e por que motivo.

Espero que isso lhe forneça informações de qualidade em seus próprios projetos.

Pontos fortes do GitLab CI e Jenkins

IC do GitLab

O GitLab CI é naturalmente integrado no GitLab SCM. Você pode criar pipelines usando gitlab-ci.ymlarquivos e manipulá-los através de uma interface gráfica.

Esses pipelines como código podem obviamente ser armazenados na base de código, impondo a prática "tudo como código" (acesso, controle de versão, reprodutibilidade, reutilização etc.).

O GitLab CI é uma ótima ferramenta de gerenciamento visual:

  • todos os membros das equipes (incluindo os não técnicos) têm acesso rápido e fácil ao status do ciclo de vida dos aplicativos.
  • portanto, pode ser usado como um painel interativo e operacional para gerenciamento de liberação.

Jenkins

Jenkins é uma ótima ferramenta de construção. Sua força está em seus muitos plugins. Especialmente, tive muita sorte em usar plugins de interface entre o Jenkins e outras ferramentas de CI ou CD. Essa é sempre uma opção melhor do que recriar (possivelmente mal) uma interface de diálogo entre dois componentes.

O pipeline como código também está disponível usando groovyscripts.

Usando o GitLab CI e Jenkins juntos

Pode parecer um pouco redundante a princípio, mas a combinação de GitLab CI e Jenkins é bastante poderosa.

  • O IC do GitLab orquestra (encadeia, executa, monitora ...) pipelines e pode-se beneficiar de sua interface gráfica integrada ao GitLab
  • Jenkins executa o trabalho e facilita o diálogo com ferramentas de terceiros.

Outro benefício desse projeto é ter um acoplamento frouxo entre as ferramentas:

  • poderíamos substituir qualquer um dos componentes da fábrica de construção sem precisar refazer todo o processo de CI / CD
  • poderíamos ter um ambiente de construção heterogêneo, combinando (possivelmente vários) o Jenkins, o TeamCity, o nome dele, e ainda ter uma única ferramenta de monitoramento.

O compromisso

Bem, é claro, há um preço a pagar por esse projeto: a configuração inicial é complicada e você precisa ter um nível mínimo de entendimento de muitas ferramentas.

Por esse motivo, eu não recomendo essa configuração, a menos que

  • você tem muitas ferramentas de terceiros para lidar. É quando Jenkins é super útil com seus muitos plugins.
  • você precisa lidar com aplicativos complexos com tecnologias heterogêneas, cada um com um ambiente de construção diferente, e ainda precisa ter uma interface de usuário de gerenciamento de ciclo de vida de aplicativos unificada.

Se você não estiver em nenhuma dessas situações, provavelmente estará melhor com apenas uma das duas, mas não com as duas.

Se eu tivesse que escolher um

O GitLab CI e Jenkins têm prós e contras. Ambos são ferramentas poderosas. Então qual escolher?

resposta 1

Escolha aquele em que sua equipe (ou alguém próximo) já possui um certo nível de experiência.

Resposta 2

Se vocês são todos novatos em tecnologias de CI, basta escolher um e seguir em frente.

  • Se você estiver usando o GitLab e tiver um talento especial para tudo como código, faz total sentido escolher o GitLab CI.
  • Se você precisar dialogar com muitas outras ferramentas de CI / CD ou precisar absolutamente dessa GUI para criar seus trabalhos, vá para Jenkins.

Aqueles de vocês que estão usando o GitLab e não têm certeza de que continuarão fazendo isso ainda precisam ter em mente que, ter escolhido o IC do GitLab implicaria na lixeira de todos os seus pipelines de CI / CD.

A palavra final é: o equilíbrio se inclina um pouco para Jenkins por causa de seus muitos plugins, mas é provável que o GitLab CI preencha rapidamente a lacuna.


@ Peter Mortensen: THX!
Avi.elkharrat 6/06/19

6

Gostaria de adicionar algumas descobertas de minhas experiências recentes com o GitLab CI. Os recursos que acompanham o 11.6 e o ​​11.7 são incríveis!

Especificamente, adoro onlycondições que basicamente permitem que você construa pipelines separados para merge_requestou push(a lista completa está aqui )

Além disso, eu realmente gosto da ausência de plugins. Quando preciso de uma funcionalidade mais complexa, basta escrever uma imagem personalizada do Docker que lida com a funcionalidade necessária (é o mesmo conceito que você pode ver no drone.io ).

Se você está pensando em DRY , é absolutamente possível hoje em dia! Você pode escrever seus "modelos"

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

Coloque-os em algum repositório público, inclua-os no pipeline principal:

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

E use-os para estender algum trabalho:

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

Eu amo tanto o GitLab CI! Sim, (até agora) não é possível desenhar bons gráficos com cobertura e assim por diante, mas no geral é uma ferramenta realmente interessante!

Edit (2019-02-23): aqui está o meu post sobre coisas que eu amo no GitLab CI. Foi escrito em 11.7 "era", portanto, quando você está lendo esta resposta, o GitLab CI provavelmente possui muitos outros recursos.

Editar (2019/07/10): gitlab CI agora suporta múltiplos extends, por exemplo

extends:
 - .pieceA
 - .pieceB

Consulte a documentação oficial para obter mais informações sobre várias extensões


0

se seus trabalhos de compilação / publicação / implantação e teste não são muito complexos, o uso do gitlab ci tem vantagens naturais.

Como o gitlab-ci.yml está presente ao lado do seu código em todas as ramificações, você pode modificar suas etapas ci / cd particularmente testes (que diferem entre os ambientes) de forma mais eficaz.

Por exemplo, você deseja fazer testes de unidade para qualquer entrada no ramo dev, enquanto você pode executar testes funcionais completos na filial do controle de qualidade e um tipo limitado de testes apenas na produção, que pode ser alcançado facilmente usando o gitlab ci.

A segunda vantagem, além da excelente interface do usuário, é a capacidade de usar imagens do docker para executar qualquer estágio, mantendo o corredor do host intacto e, portanto, menos propenso a erros.

além disso, o gitlab ci faria o check-in automaticamente para você e você não precisará gerenciar o jenkins master separadamente

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.