GitLab CI contre Jenkins

Question

Quelle est la différence entre Jenkins et d’autres CI, comme GitLab CI, drone.io, qui vient avec la distribution Git. Lors de certaines recherches, je n'ai pu que constater que l'édition communautaire de GitLab n'autorisait pas l'ajout de Jenkins, contrairement à l'édition d'entreprise de GitLab. Y a-t-il d'autres différences significatives?

Answer 1

Ceci est mon expérience:

Dans mon travail, nous gérons nos référentiels avec GitLab EE et nous avons un serveur Jenkins (1.6) en cours d'exécution.

Dans la base, ils font à peu près la même chose. Ils exécuteront des scripts sur une image serveur/Docker.

TL; DR;

• Jenkins est plus facile à utiliser/apprendre, mais il risque de devenir un enfer de plugin
• Jenkins a une interface graphique (ceci peut être préféré si elle doit être accessible/maintenable par d'autres personnes)
• L'intégration à GitLab est inférieure à celle de GitLab CI
• Jenkins peut être séparé de votre référentiel

La plupart des serveurs CI sont assez simples ( concourse.ci ), gitlab-ci , circle-ci , travis-ci , drone.io , gocd et quoi d'autre avez-vous). Ils vous permettent d'exécuter des scripts Shell/bat à partir d'une définition de fichier YAML. Jenkins est beaucoup plus connectable et est fourni avec une interface utilisateur. Cela peut être un avantage ou un inconvénient, selon vos besoins.

Jenkins est très configurable à cause de tous les plugins disponibles. L'inconvénient est que votre serveur CI peut devenir un spaghetti de plugins.

À mon avis, l'enchaînement et l'orchestration des tâches dans Jenkins sont beaucoup plus simples (à cause de l'interface utilisateur) que via YAML (appel de commandes curl). En plus de cela, Jenkins supporte les plugins qui vont installer certains binaires quand ils ne sont pas disponibles sur votre serveur (ne le savent pas pour les autres).

De nos jours ( Jenkins 2 supporte aussi plus de "bon ci" avec le plugin Jenkinsfile et le pipline qui vient par défaut à partir de Jenkins 2), mais était moins couplé au référentiel que c.-à-d. GitLab CI.

L'utilisation de fichiers YAML pour définir votre pipeline de construction (et finalement exécuter Pure Shell/bat) est plus propre.

Les plug-ins disponibles pour Jenkins vous permettent de visualiser toutes sortes de rapports, tels que les résultats de tests, la couverture et d'autres analyseurs statiques. Bien sûr, vous pouvez toujours écrire ou utiliser un outil pour le faire à votre place, mais c’est certainement un avantage pour Jenkins (en particulier pour les gestionnaires qui ont tendance à trop valoriser ces rapports).

Dernièrement, je travaille de plus en plus avec GitLab CI. Chez GitLab, ils font un travail vraiment formidable pour rendre l'expérience amusante. Je comprends que les gens utilisent Jenkins, mais lorsque GitLab est lancé et disponible, il est très facile de démarrer avec GitLab CI. Rien n'intégrera de manière aussi transparente que GitLab CI, même s'ils ont déployé des efforts considérables dans les intégrations tierces.

• Leur documentation devrait vous aider à démarrer rapidement.
• Le seuil pour commencer est très bas.
• La maintenance est facile (pas de plugins).
• La mise à l'échelle des coureurs est simple.
• CI fait pleinement partie de votre référentiel.
• Les emplois/vues de Jenkins peuvent devenir désordonnés.

Quelques avantages au moment de l'écriture:

• Ne supporte qu'un seul fichier dans l'édition communautaire. Fichiers multiples dans le édition d'entreprise .

Answer 2

Je suis d'accord avec la plupart des notes de Rik, mais mon opinion sur ce qui est le plus simple est l'inverse : GitLab s'avère être un outil formidable pour travailler.

La plus grande partie du pouvoir provient des capacités autonomes et intégrant tout dans le même produit sous le même onglet de navigateur: à partir du référentiel navigateur, panneau d'affichage ou historique de génération des outils de déploiement et surveillance .

Je l’utilise actuellement pour automatiser et tester la manière dont une application s’installe sur différentes distributions Linux. Il est simplement rapide à configurer (essayez d’ouvrir un configuration du travail Jenkins complexe dans Firefox et attendez que le script qui ne répond pas apparaisse comparé à la légèreté de l’édition .gitlab-ci.yml).

Le temps consacré à la configuration/mise à l'échelle des esclaves est considérablement réduit grâce aux exécutables binaires ; plus le fait que dans GitLab.com vous obtenez des coureurs partagés assez décents et libres.

Jenkins estime plus manuel après quelques semaines d'utilisation de GitLab CI, par ex. dupliquer les travaux par branche, installer des plugins pour réaliser des tâches simples telles que le téléchargement SCP. Le seul cas d'utilisation auquel j'ai été confronté et qui me manque aujourd'hui est celui de plusieurs référentiels; cela doit être encore bien compris.

BTW, je suis en train d'écrire une série sur GitLab CI pour montrer qu'il n'est pas si difficile de configurer votre infrastructure de CI de référentiel avec celle-ci. Publié la semaine dernière, le premier article présente les bases, les avantages, les inconvénients et les différences avec d’autres outils: Intégration continue rapide et naturelle avec GitLab CI

Answer 3

Tout d’abord, à compter d’aujourd’hui, GitLab Community Edition peut être totalement interopérable avec Jenkins. Pas de question.

Dans ce qui suit, je donne quelques retours sur une expérience réussie associant Jenkins et GitLab CI. J'examinerai également si vous devriez utiliser les deux ou seulement l'un d'entre eux et pour quelle raison.

J'espère que cela vous donnera des informations de qualité sur vos propres projets.

Forces de GitLab CI et Jenkins

GitLab CI

GitLab CI est naturellement intégré à GitLab SCM. Vous pouvez créer des pipelines à l'aide de fichiers gitlab-ci.yml et les manipuler via une interface graphique.

Ces pipelines en tant que code peuvent évidemment être stockés dans la base de code, appliquant la pratique du "tout en tant que code" (accès, gestion des versions, reproductibilité, possibilité de réutilisation, etc.).

GitLab CI est un excellent outil de gestion visuel:

• tous les membres des équipes (y compris les non techniques) ont un accès rapide et facile au statut du cycle de vie des applications.
• par conséquent, il peut être utilisé comme tableau de bord interactif et opérationnel pour la gestion des versions .

Jenkins

Jenkins est un excellent outil de construction. Sa force réside dans ses nombreux plugins. Surtout, j'ai eu beaucoup de chance dans l'utilisation de plugins d'interface entre Jenkins et d'autres outils de CI ou de CD. C'est toujours une meilleure option que de redévelopper (éventuellement mal) une interface de dialogue entre deux composants.

Le pipeline en tant que code est également disponible avec les scripts groovy.

Utiliser GitLab CI et Jenkins ensemble

Cela peut sembler un peu redondant au début, mais combiner GitLab CI et Jenkins est assez puissant.

• GitLab CI orchestre des pipelines (on enchaîne, dirige, surveille ...) et son interface graphique intégrée à GitLab permet
• Jenkins exécute le travail et facilite le dialogue avec des outils tiers.

Un autre avantage de cette conception est d'avoir un couplage lâche entre les outils:

• nous pourrions remplacer n'importe lequel des composants de l'usine de fabrication sans avoir à retravailler tout le processus CI/CD
• nous pourrions avoir un environnement de construction hétérogène, combinant (éventuellement plusieurs) Jenkins, TeamCity, etc. et tout en ayant un seul outil de surveillance.

Le compromis

Bien sûr, il y a un prix à payer pour cette conception: la configuration initiale est lourde et vous devez avoir un minimum de compréhension de nombreux outils.

Pour cette raison, je ne recommande pas une telle configuration à moins que

• vous avez de nombreux outils tiers à gérer. C'est à ce moment que Jenkins est très pratique avec ses nombreux plugins.
• vous devez gérer des applications complexes avec des technologies hétérogènes, ayant chacune un environnement de construction différent, tout en ayant toujours besoin d'une interface utilisateur unifiée pour la gestion du cycle de vie des applications.

Si vous ne vous trouvez dans aucune de ces situations, vous êtes probablement mieux avec un seul des deux, mais pas les deux.

Si je devais en choisir un

GitLab CI et Jenkins ont tous deux des avantages et des inconvénients. Les deux sont des outils puissants. Alors lequel choisir?

Réponse 1

Choisissez celui pour lequel votre équipe (ou un proche) possède déjà un certain niveau d'expertise.

Réponse 2

Si vous êtes tous débutants dans les technologies CI, choisissez-en un et lancez-vous.

• Si vous utilisez GitLab et avez le chic pour tout coder, choisir GitLab CI est tout à fait sensé.
• Si vous devez dialoguer avec de nombreux autres outils CI/CD ou si vous avez absolument besoin de cette interface graphique pour créer vos tâches, optez pour Jenkins.

Ceux d’entre vous qui utilisent GitLab et ne sont pas certains qu’ils continueront à le faire doivent garder à l’esprit qu’avoir choisi GitLab CI impliquerait de supprimer tous vos pipelines CI/CD.

Le mot final est: la balance penche un peu vers Jenkins en raison de ses nombreux plugins, mais il est probable que GitLab CI comble rapidement le vide.

Answer 4

J'aimerais ajouter quelques résultats de mes expériences récentes avec GitLab CI. Les fonctionnalités fournies avec 11.6 et 11.7 sont tout simplement géniales!

Plus précisément, j'aime les conditions only qui permettent de créer des pipelines distincts pour merge_request ou Push (la liste complète est ici )

De plus, j'aime beaucoup l'absence de plugins. Lorsque j’ai besoin de fonctionnalités plus complexes, j’écris simplement une image Docker personnalisée qui gère les fonctionnalités requises (il s’agit du même concept que celui décrit dans drone.io ).

Si vous vous interrogez sur DRY , c'est absolument possible de nos jours! Vous pouvez écrire vos "modèles"

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

Placez-les dans un référentiel public, incluez-les dans le pipeline principal:

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

Et utilisez-les pour prolonger un emploi:

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

J'aime tellement GitLab CI! Ouais, il (jusqu'à présent) ne peut pas dessiner de jolis graphes avec une couverture, etc. outil!

Edit (2019-02-23): voici mon post sur choses que j'aime dans GitLab CI. Il était écrit en 11.7 "ère", alors quand vous lisez cette réponse, GitLab CI a probablement beaucoup plus de fonctionnalités.

Edit (2019-07-10): Gitlab CI prend désormais en charge plusieurs extends par exemple.

extends:
 - .pieceA
 - .pieceB

Consultez la documentation officielle pour obtenir plus d'informations sur multiple extend