GitLab CI vs Jenkins [fermé]


129

Quelle est la différence entre Jenkins et d'autres CI comme GitLab CI, drone.io venant avec la distribution Git. D'après certaines recherches, je n'ai pu que constater que l'édition communautaire de GitLab ne permet pas d'ajouter Jenkins, contrairement à l'édition d'entreprise de GitLab. Y a-t-il d'autres différences importantes?


5
GitLab a également mis en place une comparaison de GitLab CI vs Jenkins: about.gitlab.com/comparison/gitlab-vs-jenkins.html
bbodenmiller

Réponses:


122

Voici mon expérience:

À mon travail, nous gérons nos dépôts 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 certains scripts sur une image serveur / Docker.

TL, DR;

  • Jenkins est plus facile à utiliser / apprendre, mais il risque de devenir un enfer de plugins
  • Jenkins a une interface graphique (cela peut être préféré si elle 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 référentiel

La plupart des serveurs CI sont assez simples ( concourse.ci ), gitlab-ci , circle-ci , travis-ci , drone.io , gocd et tout ce que vous avez d'autre). 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 livré avec une interface utilisateur. Cela peut être un avantage ou un inconvénient, selon 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, le chaînage et l'orchestration des tâches dans Jenkins sont beaucoup plus simples (à cause de l'interface utilisateur) que via YAML (appel de commandes curl). De plus, Jenkins prend en charge des plugins qui installeront certains binaires lorsqu'ils ne sont pas disponibles sur votre serveur (je ne sais pas à ce sujet pour les autres).

De nos jours ( Jenkins 2 prend également en charge plus de "bon ci" avec le Jenkinsfileet le plugin pipline qui vient par défaut à partir de Jenkins 2), mais était moins couplé au référentiel que GitLab CI.

Utiliser des fichiers YAML pour définir votre pipeline de construction (et à la fin 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 des tests, la couverture et d'autres analyseurs statiques. Bien sûr, vous pouvez toujours écrire ou utiliser un outil pour le faire pour vous, mais c'est certainement un plus 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 très bon travail pour rendre l'expérience amusante. Je comprends que les gens utilisent Jenkins, mais lorsque GitLab est en cours d'exécution et disponible, il est vraiment facile de démarrer avec GitLab CI. Il n'y aura rien qui s'intégrera aussi parfaitement que GitLab CI, même s'ils ont déployé des efforts considérables dans les intégrations tierces.

  • Leur documentation devrait vous permettre de démarrer en un rien de temps.
  • 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 partie intégrante de votre référentiel.
  • Les emplois / vues 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. Fichiers multiples dans l' édition entreprise .

13
Jenkins peut maintenant obtenir une meilleure interface graphique grâce à Blue Ocean
Ayoub Kaanich

3
À partir de gitlab 9.3, le support du pipeline multiprojet est ajouté. C'était pour moi l'une des principales raisons de s'en tenir à Jenkins. Actuellement, je fais un PoC pour vérifier si je peux gérer avec gitlab, car ils se concentrent clairement sur cela maintenant et ils évoluent beaucoup plus rapidement. En plus de cela, j'aime vraiment l'interface utilisateur et son évolution au fil du temps.
Rik

4
Le mieux avec les fichiers yaml est que vous documentez vos modifications dans le pipeline directement là où elles devraient être .. dans le référentiel dans le cadre du code source. Vous pouvez donc avoir des branches avec différents fichiers yaml pour différentes branches de version. Bien sûr, la fusion de yaml pourrait être désordonnée :) Imagerie fusionnant deux lignes de piplelines dans jenkins, c'est un travail beaucoup plus difficile.
Christian Müller

jenkins fournit beaucoup plus d'outils que gitlab ci. L'intégration de gitlab / jenkins Together est possible et est vraiment transparente pour l'utilisateur si elle est bien configurée. La fusion de deux piplelines dans jenkins est facile avec Jenkinsfile dans votre référentiel .... vous aurez besoin des plugins de branche source gitlab et gitlab
sancelot

1
Qu'entend-on par "Prise en charge d'un seul fichier dans l'édition communautaire. Fichiers multiples dans l'édition entreprise." ? Désolé, j'ai essayé de lire le numéro ci-joint, mais je n'ai pas pu comprendre.
Lester

62

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

La plus grande partie de la puissance provient du fait d'être autonome et de 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 à la surveillance .

Je l'utilise en ce moment pour automatiser et tester la façon dont une application s'installe sur différentes distributions Linux, et sa configuration est extrêmement rapide (essayez d'ouvrir une configuration de travail Jenkins complexe dans Firefox et attendez que le script non réactif apparaisse contre . combien léger est à éditer .gitlab-ci.yml).

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

Jenkins se sent plus manuel après quelques semaines d'être un utilisateur expérimenté de GitLab CI, par exemple en dupliquant des tâches par branche, en installant des plugins pour faire des choses simples telles que le téléchargement SCP. Le seul cas d'utilisation auquel j'ai été confronté où il me manque comme pour aujourd'hui est celui où plus d'un référentiel est impliqué; cela doit encore être bien compris.

BTW, j'écris actuellement une série sur GitLab CI pour montrer comment il n'est pas si difficile de configurer votre infrastructure CI de référentiel avec elle. Publié la semaine dernière, le premier article présente les bases, les avantages et les inconvénients et les différences avec d'autres outils: Intégration continue rapide et naturelle avec GitLab CI


5
Je suis totalement d'accord avec vous à propos de Gitlab. Au moment d'écrire ces lignes, gitlab n'était pas aussi complet qu'aujourd'hui. J'aime beaucoup Gitlab en tant qu'outil et j'apprécie vraiment tout le travail que les gars y mettent.
Rik

1
@alfageme: Je vais vérifier vos rapports sur le site mentionné Quoi qu'il en soit: Merci à toutes vos explications. À ce moment précis, je vais décider si nous utilisons gitlabCI ou Jenkins pour notre CI -Stuff.
Max Schindler

3
@Rik J'aime Gitlab CI, mais j'entends des arguments de l'autre côté disant qu'il est difficile de maintenir les fichiers yaml car il n'y a pas de réutilisabilité car beaucoup de fichiers yaml dans un pipeline suivent la même structure et la création de modèles n'est pas considérée comme une option supérieure pour jenkinsfile car jenkinsfile utilise groovy. il s'agit donc de code vs configuration pour la réutilisabilité. pouvez-vous s'il vous plaît partager vos réflexions à ce sujet?
user1870400

1
@ user1870400 Je ne suis pas tout à fait sûr de ce que vous entendez par modèle. Parce que pour autant que je puisse le voir, ce n'est qu'un fichier dans votre référentiel. Et ce n'est pas différent du vôtre Jenkinsfile. Vous avez raison de dire que Jenkinsfilevous avez groovy (+ bibliothèques java supplémentaires) disponibles pour exécuter du code, où le .gitlab-ci.yamlfichier supportera principalement le shell, mais (en fonction de l'emplacement du runner). D'un autre côté, vous pouvez également appeler tout cela à partir d'un script shell, mais l'inconvénient est que vous créez des dépendances machine (qui à mon avis ne sont pas très transparentes).
Rik

1
@Alfageme - J'ai également commencé à utiliser Gitlab CI et à m'éloigner de Jenkins. Je l'utilise en ce moment pour la construction automatique, le téléchargement sur Nexus, le déploiement sur DEV et l'exécution de tests unitaires. Une telle séquence est exécutée au niveau du projet (standard). Après DEV, j'ai également besoin de gérer le déploiement multi-projets (groupe Gitlab). J'ai créé une interface graphique qui utilise Gitlab, les API Nexus, etc. où vous sélectionnez le dernier TAG du projet à déployer et les derniers tags des projets de groupe sont également déployés (naïf). Je travaille sur l'extension pour prendre en charge la définition de la matrice de version (projec1v1.1 est compatible avec project2v3.2), je vais faire une demande de fonctionnalité sur gitlab pour cela.
kensai

22

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

Dans ce qui suit, je donne quelques commentaires sur une expérience réussie combinant à la fois Jenkins et GitLab CI. Je discuterai également si vous devez utiliser les deux ou un seul d'entre eux, et pour quelle raison.

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

Points forts de GitLab CI et Jenkins

GitLab CI

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

Ces pipelines sous forme de code peuvent évidemment être stockés dans la base de code, en imposant la pratique «tout en tant que code» (accès, versionnage, reproductibilité, réutilisabilité, etc.).

GitLab CI est un excellent outil de gestion visuelle:

  • tous les membres des équipes (y compris les non techniques) ont un accès rapide et facile à l'état du cycle de vie des applications.
  • il peut donc être utilisé comme un 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 d'utiliser des plugins d'interface entre Jenkins et d'autres outils CI ou CD. C'est toujours une meilleure option que de redévelopper (peut-être mal) une interface de dialogue entre deux composants.

Pipeline en tant que code est également disponible à l'aide de groovyscripts.

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 (chaînes, exécute, surveille ...) des pipelines et on peut profiter de son interface graphique intégrée à GitLab
  • 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 l'un des composants de l'usine de construction sans avoir à retravailler tout le processus CI / CD
  • nous pourrions avoir un environnement de construction hétérogène, combinant (éventuellement plusieurs) Jenkins, TeamCity, vous l'appelez, et avoir toujours 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 configuration sauf si

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

Si vous n'êtes dans aucune de ces situations, vous êtes probablement mieux avec une seule 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 dans lequel votre équipe (ou un proche) a déjà un certain niveau d'expertise.

Réponse 2

Si vous êtes tous de première année en technologies CI, choisissez-en une et lancez-vous.

  • Si vous utilisez GitLab et avez un talent pour tout comme code, il est tout à fait sensé de choisir GitLab CI.
  • 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 travaux, 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, avoir choisi GitLab CI impliquerait de détruire tous vos pipelines CI / CD.

Le dernier mot est: l'équilibre penche un peu vers Jenkins en raison de ses nombreux plugins, mais il y a de fortes chances que GitLab CI comble rapidement le vide.


@Peter Mortensen: THX!
avi.elkharrat

6

Je voudrais 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 onlyconditions qui vous permettent essentiellement de créer des pipelines séparés pour merge_requestou 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 (c'est le même concept que vous pouvez voir dans drone.io ).

Si vous vous interrogez sur DRY , 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 référentiel public, incluez-les dans le pipeline principal:

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

Et utilisez-les pour prolonger votre travail:

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

J'aime tellement GitLab CI! Oui, il (jusqu'à présent) ne peut pas dessiner de beaux graphiques avec une couverture, etc., mais dans l'ensemble, c'est un outil vraiment sympa!

Edit (23/02/2019): voici mon article sur les choses que j'aime dans GitLab CI. Il a été écrit en 11.7 "ère" donc 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 extendspar exemple

extends:
 - .pieceA
 - .pieceB

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


0

si vos travaux de construction / publication / 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, en particulier les tests (qui diffèrent selon les environnements).

Par exemple, vous voulez faire des tests unitaires pour toute consignation dans la branche dev, alors que vous voudrez peut-être effectuer des tests fonctionnels complets sur la branche QA et un type limité de tests en production uniquement, cela peut être réalisé facilement en utilisant gitlab ci.

Le deuxième avantage en dehors de la grande interface utilisateur est sa capacité à utiliser des images de docker pour exécuter n'importe quelle étape, ce qui permet de garder le coureur hôte intact et donc moins sujet aux erreurs.

de plus, gitlab ci s'enregistrerait automatiquement pour vous et vous n'avez pas à gérer jenkins master séparément

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.