GitLab CI vs. Jenkins

Question

Quelle est la différence entre Jenkins et d'autres CI comme GitLab CI, drone.io qui viennent avec la distribution Git. Après quelques recherches, je n'ai pu que constater que l'édition communautaire de GitLab ne permet pas d'ajouter Jenkins, alors que l'édition entreprise de GitLab le permet. Existe-t-il d'autres différences significatives ?

Answer 1

C'est mon expérience :

À mon travail, nous gérons nos dépôts avec GitLab EE et nous avons un serveur Jenkins (1.6) en fonctionnement.

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

TL;DR ;

• Jenkins est plus facile à utiliser/apprendre, mais il présente le risque de devenir un enfer de plugins.
• Jenkins a une interface graphique (cela peut être préféré s'il doit être accessible/maintenable par d'autres personnes).
• L'intégration avec GitLab est moindre qu'avec GitLab CI.
• Jenkins peut être séparé de votre dépôt.

La plupart des serveurs CI sont assez simples ( concourse.ci ), gitlab-ci , circle-ci , travis-ci , drone.io , gocd et tout ce que vous voulez). Ils vous permettent d'exécuter des scripts shell/bat à partir d'une définition de fichier YAML. Jenkins est beaucoup plus enfichable et est livré avec une interface utilisateur. Cela peut être un avantage ou un inconvénient, en fonction de vos besoins.

Jenkins est très configurable grâce à 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 (grâce à l'interface utilisateur) que via YAML (en appelant des commandes curl). De plus, Jenkins supporte des plugins qui installent certains binaires lorsqu'ils ne sont pas disponibles sur votre serveur (je ne sais pas si c'est le cas pour les autres).

De nos jours ( Jenkins 2 soutient également plus de "proper ci" avec le Jenkinsfile et le pipline qui est fourni par défaut à partir de Jenkins 2), mais qui était moins couplé au référentiel que GitLab CI.

L'utilisation de fichiers YAML pour définir votre pipeline de construction (et, à la fin, l'exécution pure de shell/bat) est plus propre.

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

Dernièrement, j'ai travaillé de plus en plus avec GitLab CI. Chez GitLab, ils font un excellent travail pour rendre l'expérience amusante. Je comprends que les gens utilisent Jenkins, mais lorsque vous avez GitLab qui fonctionne et qui est disponible, il est vraiment facile de démarrer avec GitLab CI. Il n'y aura rien qui s'intégrera de manière aussi transparente que GitLab CI, même s'ils ont fait des efforts considérables en matière d'intégrations tierces.

• Leur documentation devrait vous permettre de démarrer en un rien de temps.
• Le seuil de départ est très bas.
• La maintenance est facile (pas de plugins).
• La mise à l'échelle des coureurs est simple.
• CI fait partie intégrante de votre référentiel.
• Les travaux/visites de Jenkins peuvent devenir désordonnés.

Quelques avantages au moment de la rédaction :

• Prise en charge d'un seul fichier dans l'édition communautaire. Des fichiers multiples dans l'édition édition 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 la suivante le contraire : GitLab s'avère être un outil génial pour travailler.

La plupart du pouvoir vient du fait d'être autonome et tout intégrer dans le même produit, sous le même onglet de navigateur : du navigateur de référentiel, du tableau des problèmes ou de l'historique de construction aux outils de déploiement et à l suivi de .

Je l'utilise en ce moment pour automatiser et tester l'installation d'une application sur différentes distributions Linux, et c'est tout simplement une configuration très rapide (essayez d'ouvrir une configuration complexe d'une tâche Jenkins dans Firefox et attendez que le script non réactif s'affiche par rapport à la légèreté de l'édition. .gitlab-ci.yml ).

Le temps consacré à la configuration et à la mise à l'échelle des esclaves est considérablement réduit grâce à la fonction binaires du runner et le fait qu'en GitLab.com vous obtenez des coureurs partagés tout à fait décents et gratuits.

Jenkins pense plus de manuel après quelques semaines d'utilisation intensive de GitLab CI, par exemple en dupliquant les tâches par branche, en installant des plugins pour faire des choses simples comme le téléchargement SCP. Le seul cas d'utilisation auquel j'ai été confronté et qui me manque pour le moment est celui où plus d'un dépôt est impliqué ; cela doit encore être bien étudié.

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

Answer 3

Tout d'abord, à partir d'aujourd'hui, GitLab Community Edition peut être entièrement interopérable avec Jenkins. Sans aucun doute.

Dans ce qui suit, je donne quelques retours sur une expérience réussie en combinant à la fois Jenkins et GitLab CI. Je discute également de la question de savoir si vous devez 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é pour vos propres projets.

Points forts de GitLab CI et Jenkins

GitLab CI

GitLab CI est naturellement intégré à GitLab SCM. Vous pouvez créer des pipelines en utilisant gitlab-ci.yml et de les manipuler à travers une interface graphique.

Ces pipelines sous forme de code peuvent évidemment être stockés dans la base de code, ce qui renforce la pratique du "tout sous forme de code" (accès, versionnement, reproductibilité, réutilisation, etc.)

GitLab CI est un excellent outil de gestion visuelle :

• tous les membres des équipes (y compris les non-techniciens) ont un accès rapide et facile à l'état du cycle de vie des applications.
• Il peut donc être utilisé comme un interactive et opérationnel tableau de bord pour la gestion des versions.

Jenkins

Jenkins est un excellent outil de construction. Sa force réside dans ses nombreux plugins. En particulier, j'ai eu beaucoup de chance en utilisant des 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 en utilisant groovy scripts.

Utiliser GitLab CI et Jenkins ensemble

Cela peut sembler un peu redondant au premier abord, mais combiner GitLab CI et Jenkins est assez puissant.

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

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

• nous pourrions remplacer n'importe quel composant de l'usine de construction sans avoir à retravailler l'ensemble du processus CI/CD
• nous pourrions avoir un environnement de construction hétérogène, combinant (éventuellement plusieurs) Jenkins, TeamCity, etc., tout en disposant d'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 niveau minimal de compréhension de nombreux outils.

Pour cette raison, je ne recommande pas une telle installation, sauf si

• vous devez faire face à de nombreux outils tiers. C'est là que Jenkins se révèle très utile grâce à 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 besoin d'une interface utilisateur unifiée pour la gestion du cycle de vie des applications.

Si vous n'êtes dans aucune de ces deux situations, il est probablement préférable de choisir l'une 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. Ce sont tous deux des outils puissants. Alors lequel choisir ?

Réponse 1

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

Réponse 2

Si vous êtes tout à fait novice en matière de technologies d'IC, choisissez-en une et lancez-vous.

• Si vous utilisez GitLab et que vous avez un penchant pour tout ce qui est code, il est tout à fait logique de choisir GitLab CI.
• Si vous devez dialoguer avec de nombreux autres outils de 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 qui ne sont pas sûrs de continuer à le faire doivent garder à l'esprit que le fait d'avoir choisi GitLab CI impliquerait de mettre à la poubelle tous vos pipelines CI / CD.

Le mot de la fin est : la balance penche un petit un peu vers Jenkins en raison de ses nombreux plugins, mais il y a fort à parier que GitLab CI comblera rapidement le vide.

Answer 4

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

Plus précisément, j'aime only qui vous permettent essentiellement de construire des pipelines séparés pour merge_request ou push (la liste complète est ici )

De plus, j'apprécie vraiment l'absence de plugins. Lorsque j'ai besoin d'une fonctionnalité plus complexe, il me suffit d'écrire une image Docker personnalisée qui gère la fonctionnalité requise (c'est le même concept que vous pouvez voir dans drone.io ).

Si vous vous interrogez sur SEC c'est tout à fait possible de nos jours ! Vous pouvez écrire vos "modèles".

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

Mettez-les dans un dépôt public, incluez-les dans le pipeline principal :

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

Et les utiliser pour prolonger un travail :

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

J'aime tellement GitLab CI ! Oui, il ne peut pas (jusqu'à présent) dessiner de beaux graphiques avec la couverture et ainsi de suite, mais dans l'ensemble, c'est un outil très intéressant !

Modifier (2019-02-23) : voici mon billet sur les choses que j'aime dans GitLab CI. Il a été écrit à l'"ère" 11.7, donc lorsque vous lisez cette réponse, GitLab CI a probablement beaucoup plus de fonctionnalités.

Modifier (2019-07-10) : Gitlab CI supporte maintenant plusieurs extends par exemple

extends:
 - .pieceA
 - .pieceB

Consultez la documentation officielle pour obtenir plus d'informations sur plusieurs extensions

Answer 5

Si vos tâches de construction/publipostage/déploiement et de test ne sont pas très complexes, l'utilisation de gitlab ci présente des avantages naturels.

Puisque gitlab-ci.yml est présent à côté de votre code dans chaque branche, vous pouvez modifier plus efficacement vos étapes ci/cd, notamment les tests (qui diffèrent selon les environnements).

Par exemple, vous voulez faire des tests unitaires pour tout checkin sur la branche dev, alors que vous pourriez vouloir effectuer des tests fonctionnels complets sur la branche QA et un type de tests limités sur la production, ce qui peut être réalisé facilement en utilisant gitlab ci.

Le deuxième avantage, en dehors de l'excellente interface utilisateur, est sa capacité à utiliser des images Docker pour exécuter n'importe quelle étape, ce qui permet de conserver le gestionnaire hôte intact et donc de réduire les risques d'erreur.

de plus, gitlab ci fera automatiquement le check-in pour vous et vous n'aurez pas à gérer le master jenkins séparément.