Achei a opinião desse cara nesse pequeno vídeo bem bacana e ponderada: https://www.youtube.com/watch?v=99kA0b9Xb8o
A seguir temos a tradução livre dos artigos acima. Em seguida eu escrevo a minha opinião final mostrando os principais pontos que tornam o GitLab uma melhor opção para a implementação de DevOps em uma organização.
OBSERVAÇÃO: nas traduções, os textos [entre colchetes] são colocações minhas.
Texto original: https://about.gitlab.com/devops-tools/jenkins-vs-gitlab/jenkins-gaps/
Jenkins não é uma plataforma “end to end” para todo o ciclo de vida DevOps.
Para extender as funcionalidades nativas do Jenkins é necessário a instalação de plugins. E Plugins são caros de se manter seguros e atualizados.
A maioria das organizações que conversamos nos dizem que o gerenciamento de plugins do Jenkins é um pesadelo. Cada um tem seu próprio ciclo de vida de desenvolviemnto, e toda vez que um novo plugin chega eles precião re-testar toda a cadeia de ferramentas.
Ouvimos histórias tipo Grupo precisa do Plugin A, e administrador do Jenkins instala, e então descobre que tal plugin depende de uma versão nova (e incompatível) de uma biblioteca que o requerida pelo Plugin B, que é usado pelo Grupo B.
Solução? Dar a cada grupo seu próprio servidor Jenkins? Mas então você acaba com o espalhamento do Jenkins (mais servidores para administrar). Sem mencionar toda a manutenção e testes exigidos por todas as ferramentas integradas externamente na cadeia de ferramentas.
[Achei estranho o fato deste relato não ter referência alguma a quem o fez. Mas me parece que pessoas acostumadas com o Jenkins irão concordar.]
Jenkins rapidamente se estabeleceu como uma ferramenta líder em orquestração de builds logo após sua criação em 2005 e continuou ganhando força antes que o termo “DevOps” e “CI/CD” fossem essa loucura que se ouve falar hoje em dia. Como diz o ditado, “o tempo não pára para ninguém” e estamos vendo avanços na tecnologia de desenvolvimento de software mais rápidos do que nunca.
Os padrões de 20 anos atrás parecem estranhos e o que funcionou 5 anos atrás provavelmente não será mais considerado a melhor prática. Estamos tendo que nos adaptar rapidamente para permanecermos relevantes e competir no atual clima tecnológico.
Infelizmente para o Jenkins, o que funcionou tão bem 15 anos atrás não resistiu ao teste do tempo. E a falta de inovação para se manter atualizado e melhorar o projeto afetou sua comunidade aparentemente cada vez menor de usuários e colaboradores, pelo menos em comparação com o quão próspera a comunidade já foi.
Os dois principais diferenciais do Jenkins:
Este pontos se tornaram um cenário de faca de dois gumes, onde o ecossistema de plugins cresceu a uma escala que é difícil de manter, mas ainda assim um fator crítico para suprir necessidades que o Jenkins não suporta nativamente.
O Jenkins por si só é uma aplicação java com uma UI/UX ultrapassada, e problemas desta natureza são agravantes para desenvolvedores que tentam usá-lo com eficiência e eficácia - uma batalha constante. Além disso, a comunidade, que já foi próspera, tem visto uma diminuição consistentemente significativa na atividade e na adoção.
Embora o Jenkins seja ótimo para automatizar algumas coisas, ele é muito frágil e prejudica a experiência do desenvolvedor. Especificamente:
[Achei uma análise um pouco enviesada e carente de fontes. Por exemplo: De onde vem os dados que comprovam que a adoção e a comunidade de colaboradores está diminuindo?]
Jenkins X tem altos requisitos de sistema, deployment limitado apenas a clusters Kubernetes. Só tem interface de linha de comando (no momento) e ainda usa Groovy.
[Achei o argumento bem fraco.]
Do GitLab PMM:
Jenkins teve que construir um novo projeto separado para trabalhar com o Kubernetes. O GitLab adotou nativamente o Kubernetes desde o início.
Texto original: https://about.gitlab.com/devops-tools/jenkins-vs-gitlab/gitlab-differentiators/
GitLab provê mais do que o Jenkins espera evoluir, fornecendo uma única aplicação totalmente integrada para todo o ciclo de vida DevOps.
Mais do que os objetivos do Jenkins, o GitLab também fornece planejamento, SCM (controle de versionamento de código), empacotamento, release, configuração e monitoramento (além do CI/CD que é o foco do Jenkins).
Com GitLab, não há necessidade de plugins e customização. Ao contrário do Jenkins, o GitLab é um núcleo aberto e qualquer pessoa pode contribuir com alterações diretamente para a base de código, que, uma vez mesclada, seria automaticamente testada e mantida com cada alteração.
GitLab é fácil de manter e atualizar. Para atualizar, apenas substitua uma imagem docker. Quando você atualiza uma versão, ele atualiza tudo.
Manter as definições da pipeline é mais fácil e mais limpo do que no Jenkins. O arquivo de configuração do GitLab CI/CD (.gitlab-ci.yml):
.gitlab-ci.yml também estão correndo risco de ficarem difíceis de manter.]GitLab possui:
O GitLab Runner, que executa seus trabalhos CI/CD, tem uma arquitetura de execução mais adaptável que o Jenkins.
GitLab possui um modelo de permissão única que torna mais fácil a configuração de funções e permissões.
Os pontos diferenciais “matadores” em favor do GitLab são:
.gitlab-ci.yml armazenado no mesmo repositório do código da aplicação.