Cet article évalue les avantages et les inconvénients de la mise en œuvre d’une infrastructure dédiée au CI/CD par rapport au CI/CD en tant que service, afin de comprendre si Jenkins est toujours une option de CI/CD viable.
Pour évaluer ce qui précède, il est impératif de comprendre d’abord les points suivants
- Qu’est-ce que le CI/CD
- Qu’est-ce que l’infrastructure dédiée CI/CD / CI/CD en tant que service
Qu’est-ce que le CI/CD ?
Imaginez que vous ayez une équipe de développeurs Java qui apportent continuellement des modifications au code dans un référentiel ; un outil de CI/CD reprendrait ces modifications et élaborerait la solution. C’est ce qu’on appelle l’intégration continue (IC) – la pratique consistant à automatiser l’intégration des modifications du code provenant de plusieurs contributeurs dans un seul projet logiciel. Ces changements seraient diffusés dans des environnements de développement par étapes, connus sous le nom de livraison/déploiement continus (CD).
Qu’est-ce que l’infrastructure dédiée CI/CD / CI/CD en tant que service ?
Maintenant que nous avons compris ce qu’est le CI/CD, comment cet outil est-il fourni ?
L’une des façons de proposer le CI/CD consiste à installer un outil de CI/CD tel que Jenkins sur votre propre machine, qu’il s’agisse de votre propre serveur physique ou d’une machine virtuelle dans le Cloud. Jenkins est un outil d’automatisation écrit en Java avec des plugins conçus pour l’intégration continue. Jenkins est utilisé pour construire et tester en continu des projets logiciels, ce qui permet aux développeurs d’intégrer plus facilement les modifications apportées au projet et aux utilisateurs d’obtenir plus facilement une nouvelle version.
Une autre manière d’utiliser le CI/CD est le concept de « CI/CD-as-a-Service ». Au lieu de posséder une machine dédiée pour héberger Jenkins, par exemple, vous pouvez adopter un service similaire proposé en line. Un excellent exemple d’un tel outil serait Azure DevOps. Azure DevOps est une plateforme logicielle (SaaS) de Microsoft qui fournit une chaîne d’outils DevOps de bout en bout pour développer et déployer des logiciels. Cela comprend des tableaux Kanban pour la gestion de projets, un wiki pour la communication collaborative, des outils de test pour les membres de votre équipe d’assurance qualité ainsi que le référentiel et les automatisations du pipeline.
Jenkins CI/CD Instances vs CI/CD-as-a-Service
Évaluons maintenant l’intérêt d’utiliser Jenkins Instances par rapport à des services CI/CD-as-a-Service tels que Azure DevOps.
Rien n’est gratuit dans la vie
Jenkins est un outil open-source, ce qui signifie qu’il est gratuit. Vous devrez cependant héberger Jenkins sur un serveur, ce qui coûte de l’argent. En revanche, Azure DevOps est gratuit pour les projets open-source et les petits projets, mais seulement pour un maximum de cinq utilisateurs. Pour les équipes plus importantes, les membres de VisualStudio et de MSDN qui apportent leur propre licence, les coûts vont de 30 dollars par mois (10 utilisateurs) à 6 150 dollars par mois (1 000 utilisateurs). Par conséquent, si vous avez une petite équipe avec un petit projet ou si vous invitez les membres de MSDN à contribuer, Azure DevOps pourrait être la solution.
Maintenance
Puisque Jenkins sera détenu sur une instance, vous serez responsable de la maintenance de la machine. En d’autres termes, si votre équipe est en train d’effectuer un déploiement vers la production et que la machine hébergeant Jenkins tombe en panne, vous devez mettre en place des mécanismes pour éviter que les déploiements ne soient bloqués. Le CI/CD-as-a-Service, quant à lui, est maintenu par le fournisseur. Par conséquent, les risques d’interruption de service sont rares car de nombreuses procédures ont été mises en place pour assurer une haute disponibilité.
Performance
Les performances de l’exécution de Jenkins sur une machine dédiée dépendent vraiment des spécifications de la machine et de la connectivité. L’interface peut parfois être lente et vous pouvez vous retrouver à attendre pour cliquer sur le bouton de construction. Les esclaves Jenkins (travailleurs) sont également déployés sur une infrastructure propre, et il y a un coût associé. Azure DevOps, en revanche (en tant que service), fonctionne sur une infrastructure évolutive et ne connaît donc pas ce problème. Il convient de noter que les « travailleurs » qui effectuent la construction sont souvent des systèmes distincts, et que la spécification de ces instances est donc importante. Les travailleurs ont l’avantage de pouvoir utiliser plusieurs systèmes d’exploitation pour développer et construire l’automatisation. Ils peuvent également être placés dans des réseaux internes auxquels Azure DevOps ou Jenkins ne peuvent pas accéder directement, ce qui permet de maintenir les frontières de sécurité. Azure DevOps a le grand avantage de disposer d’un énorme réservoir de travailleurs publics à utiliser gratuitement.
Configurer les scripts de pipelines
Comme Azure DevOps permet de se connecter facilement à d’autres outils tels que Terraform, ARM ou .NET, il fournit des mécanismes simples pour configurer les pipelines sous forme de code sans devoir introduire un mot de YAML. Il existe un énorme marché en ligne qui propose des milliers de plugins et d’outils à cette fin. Par exemple, vous pouvez configurer un fichier YAML pour déployer automatiquement votre code Terraform en accédant simplement à l’interface graphique Azure DevOps pour remplir automatiquement le code tel que l’exécution de Terraform init, plan et apply. L’interface utilisateur de Jenkins est très obsolète. Vous ne serez donc pas en mesure d’effectuer une telle tâche. Cette tâche est idéale si vous êtes novice dans l’écriture de pipelines à l’aide de code et que vous souhaitez simplement lancer l’automatisation.
Analytique
Contrairement à Jenkins, Azure DevOps fournit des analyses granulaires à la fin de chaque exécution, avec des paramètres comme le taux et la durée. Cette fonctionnalité est utile pour identifier les moyens d’améliorer les performances des déploiements. Elle est également utile lors de la création de carnets d’exécution de déploiement de projet, car elle fournit des prédictions plus précises pour le déploiement de l’infrastructure en production dans une fenêtre de temps.
En résumé
Jenkins est toujours une option que la plupart des clients choisissent, et cela dépend des exigences de votre projet et de la taille de votre équipe. Si vous souhaitez gérer vos constructions et déploiements en privé au sein de votre infrastructure physique, Jenkins est la solution. Si vous avez une petite équipe et que vous voulez commencer à construire et à déployer votre code rapidement, alors Azure DevOps est un outil à adopter.
