Techradar - Empowering

Adopt

50ArgoCD

ArgoCD est une plateforme de Continuous Delivery (CD) GitOps qui permet le déploiement de manière déclarative d’applications dans des clusters Kubernetes.

ArgoCD est un outil open source de Continuous Delivery (CD) pour Kubernetes, basé sur une approche GitOps. Il déploie des ressources dans des clusters, en utilisant un ou plusieurs repositories Git comme source de vérité. L'outil utilise une Custom Resource appelée Application, où l'on définit des paramètres tels que le repository source, le namespace, le cluster Kubernetes de destination, et la stratégie de réconciliation. ArgoCD supporte plusieurs types de sources pour déployer des ressources dans Kubernetes : charts Helm, applications Kustomize, fichiers Jsonnet ou encore de simples manifestes.

Pour subvenir à des besoins plus avancés, la Custom Resource ApplicationSet et son contrôleur associé permet de générer plusieurs Applications ArgoCD à partir d’un unique manifeste. En utilisant les generators et les templates d’ApplicationSet, il est alors possible de déployer plusieurs applications dans plusieurs clusters Kubernetes, tout ceci dans une spécification centralisée !

C’est une plateforme qui trouve son intérêt dans le fait que la gestion des applications et des ressources dans Kubernetes peuvent mener à des erreurs humaines ou des incohérences. Par son fonctionnement, ArgoCD se veut simple à utiliser et à configurer : ce qui est défini dans votre repository Git représente ce qui est déployé dans votre cluster Kubernetes. En effet, il bénéficie d’une fonctionnalité qui lui permet de vérifier l’état des ressources à intervalle régulier, afin de le réconcilier automatiquement si nécessaire. Par conséquent, c’est un outil sécurisant tant pour les développeurs que pour les administrateurs.

ArgoCD se veut aussi modulaire : vous pouvez gérer et mettre à jour automatiquement les versions d'images de conteneurs dans votre cluster avec ArgoCD Image Updater, suivant les principes GitOps. Avec ArgoCD Notifications, vous obtenez du monitoring et de l’alerting sur les déploiements d'applications, bien que cette fonctionnalité soit encore immature.

La force d’ArgoCD réside dans son interface utilisateur, qui permet en un clin d’œil de comprendre l’état actuel des ressources, leur statut de synchronisation avec le repository source ou encore l’état des Pods associés à l’Application. En quelques clics seulement, nous arrivons vite à comprendre que cette Application déploie plusieurs ressources, comme un Service ou un Deployment. À son tour, un Deployment provoque la création d’un ou plusieurs Pods, ce qui est également pris en compte dans l’interface.

Pour ces raisons, ArgoCD est devenu chez Theodo Cloud le standard vers lequel se tourner lorsqu’il s’agit de déployer des applications dans Kubernetes. Chez nombre de nos clients, l’implémentation d’ArgoCD a permis aux développeurs de mettre un pied dans le monde de l’infrastructure, en utilisant un environnement rassurant et une utilisation au quotidien qui s’avère simplissime.

51ELK

La stack ELK (Elasticsearch Logstash Kibana) propose une solution complète pour la gestion des logs et des performances de vos applications.

La stack ELK (Elasticsearch, Logstash, Kibana) est la suite populaire d'outils open source, développés par l'équipe Elastic.

Elle permet de stocker, indexer, visualiser et analyser les logs et performances de vos applications et de vos outils.

La stack permettra de répondre à plusieurs des enjeux des architectures et des applications modernes :

Centralisation des logs applicatifs et d’infrastructure
Visualisation en temps réel
Suivi des performances de vos applications et de vos outils (APM)
Mise en place de dashboard métier avec Kibana
Détection d’anomalies et mise en place d’alerting

La suite peut être complexe à déployer et à maintenir. Une bonne expertise des différents outils est nécessaire sur le long terme pour mettre à jour et faire évoluer la plateforme par rapport à vos besoins.

Outre le coût de la maintenance, la suite complète pourra demander beaucoup de ressources (CPU, RAM et espace disque) en fonction de la quantité (historique) de logs que vous allez traiter.

Dans ce contexte, on ne saurait trop vous recommander d’utiliser l’opérateur Kubernetes ELK pour déployer la stack. La gestion n’en sera que facilitée, notamment pour des déploiements modestes.

Sur le long terme, vous devrez vous appuyer sur de compétences techniques solides et des connaissances approfondie sur chaque composantes. Il est essentiel de bien comprendre comment configurer des paramètres avancés pour la gestion de vos logs (rotation, sauvegarde, purge, etc).

Cependant, investir du temps et des efforts pour maîtriser la stack ELK en vaut véritablement la peine. Une fois en place, c’est un outil extrêmement puissant qui améliorera

l’expérience et l’efficacité de vos développeur. Ces derniers pourront alors se concentrer sur la production d'applications de meilleure qualité, plus stables et plus performantes.

La stack ELK est un outil puissant, exigeant techniquement, qui tiendra toutes ses promesses à long terme, à condition d’avoir les compétences techniques nécessaires. C’est un choix plus flexible et évolutif que les outils natifs des Cloud Providers.

52Helm

Helm est une solution de packaging pour le déploiement d’applications conteneurisées dans Kubernetes.

Lorsque vous utilisez Kubernetes pour déployer vos applications, le nombre de manifestes (fichier de configuration de ressource Kubernetes) augmente rapidement. Cela entraîne plusieurs problèmes :

Gérer manuellement le code et les dépendances applicatives (comme Redis, une BDD ou un reverse proxy) devient volumineux et coûteux à maintenir.
Versionner un ensemble de ressources Kubernetes en une seule application est très complexe
Déployer une même application dans plusieurs environnements va demander de la duplication de code

Helm répond à tous ces problèmes. Son atout réside dans l’utilisation du moteur de templating du langage Go. Grâce à ce dernier, la création de manifestes Kubernetes est transformée en l’application de values (variables dépendant du contexte de déploiement) à des templates (manifestes Kubernetes agrémentées de balises de templating).

L’ensemble des templates et du fichier de values par défaut constitue un chart. Un chart est versionné et peut être déployé dans un cluster Kubernetes (on déploie alors une release Helm). D’autres charts peuvent être déclarés en tant que dépendances, permettant ainsi de déployer des stacks applicatives complètes.

La CLI permet de déployer des charts locaux ou distants, étant donné que Helm apporte la possibilité de créer des registries de charts. Elle permet de déployer des versions précises, effectuer des mises à jour ou des rollbacks de ses applications. Nous utilisons des charts pour déployer Prometheus/ Grafana, Cert-Manager, Cluster Autoscaler ou Nginx Ingress Controller entre autres.

Chez Theodo Cloud, nous avons créé une librairie de charts Helm pour les applications que l’on utilise le plus chez nos clients. Elle raccourcit de journées entières la mise en place d’ensembles complexes d’applications. Helm est donc un outil que nous recommandons à tous les utilisateurs de Kubernetes.

53Integrated CI/CD

La CI/CD intégrée regroupe les services tels que GitHub Actions et GitLab CI. Ils sont directement incorporés dans les plateformes éponymes, au plus proche du code.

La CI/CD (Continuous Integration / Continuous Delivery ou Continuous Deployment) représente les pratiques d'automatisation des étapes de mise en production d'une application : les tests, le build, la release et le déploiement. Des outils comme Jenkins, CircleCI et TeamCity permettent de créer des pipelines CI/ CD, et sont dits "externes" car ils n'hébergent pas le code source de l'application sur laquelle
les pipelines se basent. GitHub et GitLab sont les principales plateformes de développement Git collaboratif, avec environ 130 millions d'utilisateurs combinés. Les développeurs les utilisent quotidiennement pour coder, approuver des pull requests et gérer des issues.

Ces deux plateformes proposent leurs propres moteurs de CI/CD : GitHub Actions et GitLab CI. Grâce à des fichiers YAML, vous pouvez rapidement créer des pipelines d'automatisation qui optimisent le temps de développement. Leur free tier est généreux, évitant le besoin de payer ou de créer une infrastructure dédiée pour les petites équipes. Ces outils offrent probablement toutes les fonctionnalités nécessaires, mais des abonnements premium sont disponibles pour des besoins spécifiques ou des fonctionnalités avancées.

Au-delà de ça, les deux solutions sont auto- hébergeables. Le système de runners de GitLab CI dans Kubernetes est particulièrement bien rôdé. Il rend possible la construction rapide d’une plateforme d’exécution de jobs extensible à l’infini. Cependant, nous vous mettons en garde contre l’hébergement de vos runners si vos besoins ne s’y prêtent pas. Les coûts en maintenance et en calcul peuvent exploser. En outre, en tant que fonction clé du cycle de vie d’une application, une CI/CD instable peut rendre très difficile la vie de vos développeurs.

Malgré cela, nous recommandons à tous nos clients de se tourner vers l’une de ces deux plateformes pour créer leur CI/ CD. Leur intégration au plus près du code les rend extrêmement versatiles et réduit énormément la boucle de feedback.

Trial

55GitHub Copilot

GitHub Copilot, un outil de complétion de code basé sur l’IA très utilisé par les Ops Theodo Cloud mais encore perfectible.

Intégrable facilement à un environnement de travail comme VSCode, Github Copilot est extrêmement puissant. il permet de :

1. COMPLÉTER

Copilot est très efficace pour créer rapidement des scripts Bash simples (usage que nous privilégions) et générer du code pour des langages tels que Go, Python, JavaScript, Java, ainsi que des templates basiques en Helm et Kubernetes.

Cependant, sur des charts Helm complexes ou des ressources Terraform, il montre des limites. Les solutions proposées ne respectent pas toujours les bonnes pratiques que nous suivons chez Theodo Cloud, notamment en matière de sécurité, de principes DRY, et de lisibilité (WYSIWYG).

2. EXPLIQUER

Grâce à la possibilité de prendre la codebase en contexte, Copilot fournit des explications claires sur le code. Cela s'avère très utile pour analyser une fonction ou naviguer dans un repository inconnu.

3. CORRIGER

Copilot détecte rapidement les erreurs les plus évidentes, mais ne sait pas corriger les problèmes complexes impliquant plusieurs technologies. Par exemple, dans le cas d’ingress nginx mal configurés ou des jobs GitlabCI customs qui ne se lancent pas. Nous retenons qu’il peut donner des pistes pour debug, mais rarement donner une solution complète.

4. DOCUMENTER

Nous avons déjà largement adopté Copilot pour produire de la documentation de qualité telle que : les swaggers, les catalogues Backstage, la description d’interfaces de Chart Helm ou encore l'explication de GitHub Actions.

En conclusion, GitHub Copilot est un outil que nous utilisons au quotidien mais qui ne remplace pas encore nos SRE. En attendant une amélioration du comportement de l’outil face à des problèmes complexes, nous le classons en Trial.

56Loki

Loki est l’outil de logging natif de la stack Grafana, idéal pour les environnements Kubernetes.

Loki, développé par Grafana Labs, est un outil de logging conçu pour collecter les logs de vos applications déployées dans Kubernetes et les remonter dans Grafana. Il permet de les interroger facilement via l'interface Web.

Cet outil de logging est très simple à installer dans vos clusters Kubernetes. Il est déjà packagé dans le chart prom-stack de la communauté : vous n’avez qu’une option à activer et le tour est joué, quasiment aucune configuration supplémentaire n’est requise.

Si vous utilisez déjà Grafana, vous pourrez créer des dashboards complets combinant les métriques et logs de vos applications, pour le monitoring et debugging. Rien de mieux pour rendre vos développeurs complètement autonomes dans la gestion de leur application ! Loki offre également la possibilité de mettre en place une rétention de logs sur le long terme en envoyant l’historique dans des buckets. Cependant, l’outil n’est pas optimisé pour faire de la recherche sur des logs archivés : la recherche directe dans les logs accessibles dans votre cluster Kubernetes est plus performante que la recherche dans des logs archivés qui doivent être rapatriés, décryptés et indexés.

Inconvénient : le langage qui sert à requêter les logs internes à Loki, le LogQL, n’est pas le plus facile à appréhender et maîtriser. La syntaxe est différente des langages de requête traditionnels et nécessite de bien comprendre ce qu’est un range vector. Voici un exemple de requête LogQL pour illustrer cette différence : {app="example-app"} |= "error"

Si vous utilisez déjà Grafana pour vos dashboards et cherchez une solution facile à mettre en place pour le logging et le debugging de vos clusters Kubernetes, Loki est un excellent choix. Cependant, gardez à l'esprit que Loki n'est pas optimisé pour la rétention long terme de logs et que LogQL demande un peu d'apprentissage.

57Platform Engineering

Le Platform Engineering est une manière de concevoir son infrastructure comme un produit dont les développeurs sont les utilisateurs.

À l’origine, le Cloud promettait de simplifier l'administration système en abstrayant sa complexité. Mais la maturité du Cloud et l'augmentation des services en découlant (plus de 200 sur AWS), ont complexifié le paysage. La mouvance DevOps cherche à répondre à ce défi en intégrant des profils spécialisés pour apporter une expertise sans friction à l'équipe.

Pourtant, le DevOps est difficile à faire passer à l’échelle et les DevOps (re)deviennent le goulet d’étranglement du delivery :

Le paysage des technologies et services se densifie, les pratiques et patterns évoluent.
Pour que l’adage “You build it, you run it” reste vrai, les développeurs ont un besoin d’expertise qui dépasse souvent leur champ de compétences. Certaines Digital Factory abordent le Platform. Engineering en produisant des outils communs pour toutes les business units de leur groupe. Cependant, cette démarche exige un apprentissage de l’approche produit, complètement nouvelle pour une DSI historique. L’impact ? Une plateforme très uniformisée et sécurisée, mais qui ne répond que partiellement aux besoins méconnus des développeurs.

Pour nous, le Platform Engineering consiste à considérer l’infrastructure comme un produit à destination des développeurs. Cela a 3 implications :

• collecter les besoins et feedbacks utilisateurs régulièrement, comme on le ferait si on lançait notre service de covoiturage ;

• déterminer les jobs to be done et performances critiques du produit à construire, ses personaes, son architecture fonctionnelle ;

• repenser l’Operating Model. Notre recommandation : découper l’équipe DevOps en deux, une équipe Enabler livrant de nouveaux produits aux équipes tech, une équipe Operators assurant la fiabilité et la cohérence de la plateforme.

Le Platform Engineering est un vrai investissement de temps sur la démarche et sur le produit, il n’est donc intéressant qu’une fois passée une taille critique des équipes devs et ops.

58Preview Environments

Ils permettent de tester les changements dans un environnement réel réduisant le risque d’erreur et augmentant leur efficacité.

Les preview environments permettent aux développeurs de tester les changements sur une application avant le déploiement en production. Utilisés pour vérifier les nouvelles fonctionnalités et les mises à jour de code, ils permettent notamment de tester l'interopérabilité des sous-systèmes et de s'assurer que tout fonctionne comme prévu. Cela réduit ainsi les risques d'erreurs et le temps de correction.

Ces environnements améliorent aussi l'efficacité des développeurs qui peuvent travailler simultanément sur plusieurs fonctionnalités dans des environnements isolés. Cela diffère d’un environnement staging “classique”.

Ces environnements peuvent être créés de différentes façons. Voici la méthode que

Theodo Cloud recommande aujourd’hui :

1. À chaque ouverture de PR sur une application, on déploie, en plus de la version “stable”, la version issue de la branche.

2. Pour chaque nouvelle version déployée d’une application, on définit un header qui permet de router des requêtes dessus.

3. Pour tester une PR, il suffit de faire des requêtes en utilisant ce fameux header.

Cela fonctionne parfaitement dans un cluster Kubernetes, mais risque d'être plus compliqué à mettre en place sans.

Toutefois, si cette méthode est très efficace pour les applications en HTTP, nous n'avons pas encore de solution à proposer pour les applications event-driven.

Les preview environnements sont très utiles pour augmenter l'efficacité des développeurs de votre organisation. Cependant, ils sont un peu compliqués à mettre en place et à maintenir. Nous les recommandons donc principalement aux équipes en grande expansion.

Assess

54Sentry

Sentry est un outil puissant pour suivre et corriger les erreurs applicatives.

Sentry aide les développeurs à suivre les erreurs applicatives grâce à une interface web intuitive. En installant le SDK adapté à leur langage de programmation (Node.js, Python, Ruby, Go, Android, etc.), ils capturent les erreurs et exceptions. Cela leur permet d'obtenir des informations détaillées sur la cause première de chaque erreur, améliorant ainsi la qualité des services.

Depuis quelque temps, Sentry gagne en popularité en raison de sa capacité à fournir des informations exploitables pour améliorer la qualité du code et la fiabilité des applications. En plus de suivre les erreurs, Sentry permet de surveiller les métriques de performance des applications en temps réel, aidant ainsi à identifier les points de défaillance uniques (SPOFs) et les problèmes de scalabilité. Pour intégrer Sentry dans votre écosystème, vous avez deux possibilités : utiliser la solution SaaS (payante) ou bien l’installer en self-hosted sur votre infrastructure, comme un cluster Kubernetes. Nous vous recommandons d’utiliser la solution SaaS qui est généralement plus rentable à long terme en matière de temps consacré à la maintenance.

En effet, l’architecture applicative de Sentry est complexe avec pas moins de 10 composants à gérer. Bien que Sentry puisse être déployé avec un Chart Helm développé par la communauté, maintenir un niveau de disponibilité satisfaisant en self-hosted nécessite beaucoup de temps et d'effort pour corriger les erreurs natives du produit. Il est important de peser les avantages et les inconvénients de chaque approche selon vos besoins spécifiques.

Nous conseillons la solution SaaS de Sentry pour améliorer la qualité et la fiabilité des applications. Elle offre des mises à jour automatiques et un support direct de l’éditeur, évitant les complexités de la gestion en self- hosted. Mais pour certaines entreprises, cette dernière peut être plus adaptée pour des raisons de conformité ou de contrôle des données.

59Argo Rollouts

Argo Rollout permet facilement de mettre en place des modes de déploiement complexes (Blue-Green / Canary)

Argo Rollout, à l'instar de Flagger, est une solution permettant de faire ce qu'on appelle communément du "Blue-Green Deployment" ou des "Canary Release". Ces modes de déploiement complexes n'étaient pas à la portée de toutes les organisations avant la création de ces outils, car ils nécessitent le développement d'un outil custom et ou la mise en place de workflows complexes via des outils comme Jenkins.

Sa mise en place, comme tous les outils de l'écosystème Argo, passe par Kubernetes et de nouvelles ressources (CRD Rollout). L'outil tire judicieusement partie du support pour les subressources sur les CRD introduit en Kubernetes 1.10 pour introduire une nouvelle ressource comparable en tout point à un Deployment (en utilisant la subressource / scale), mais en complexifiant les spécifications de la stratégie de mise à jour.

Ce faisant vous pouvez désormais écrire des “déploiements à étapes” en utilisant notamment :

Des étapes de scaling (Augmentation du nombre de pods dans la nouvelle version)
Des étapes de pause
Une analyse en background pour déterminer si le déploiement doit continuer (e.g une requête à Prometheus)

Pour les modes de déploiement complexes, nous privilégions Flagger car nous l’avons davantage éprouvé sur nos projets. Cependant, nous pensons qu’Argo Rollout a de l'avenir dans la réponse à cette problématique. Les deux outils tirent parti de l'intégration à leur écosystème respectif (FluxCD pour l'un, ArgoCD pour l'autre).

Cependant, mettre en place ce genre de modes de déploiement nécessite une maturité importante et un très bon système d'observabilité.

60Backstage

Backstage est un outil couteau-suisse qui, si bien utilisé, peut devenir le point central de votre Internal Developer Platform (IDP).

Backstage est une technologie open sourcée en 2020 par Spotify dont le but est la création d'un portail développeur extensible pour votre plateforme interne.

L'idée derrière Backstage est de devenir le point de passage "obligatoire" et unique pour interagir avec votre plateforme interne. Dans sa version sans plugin additionnel, Backstage propose déjà plusieurs features intéressantes :

TechDocs qui permet d'agréger toutes les documentations au format Markdown dans votre instance Backstage ;
Software Templates qui permet la création de boilerplates pour démarrer de nouveaux services (e.g. Initialisation du repository) ;
Software Catalog qui permet de référencer les différents services;

utilitaires que vous utilisez ou développez. Il peut par ailleurs agréger toutes les specs OpenAPI ou Swagger de vos services web.

La principale force de Backstage est liée à son extensibilité. De nombreux plugins ont été développés par la communauté (e.g. Une intégration avec ArgoCD) et il est totalement possible d'imaginer développer ses propres plugins afin de satisfaire les besoins internes. Il ne convient cependant pas à toutes les organisations et n'est réellement utile qu'à partir du moment où votre équipe Tech/R&D dépasse les 50 personnes. Cette "taille critique" correspond au moment où suivre l’ensemble des évolutions de votre plateforme commence à être très complexe.

Le premier gain que nous avons pu observer avec Backstage est la facilitation de l'onboarding des développeurs et des DevOps grâce à la centralisation de la documentation technique à un seul endroit. Ceci permet un gain important sur le KPI "Time to first PR" clé dans des équipes techniques conséquentes.

Nous sommes toujours en train d'observer les gains de Backstage sur des équipes tech de tailles différentes, et c'est pourquoi il reste pour le moment dans le cadran “Assess”.

61Kubernetes native CI/CD

Les outils de CI/CD Kube native sont totalement intégrés à Kubernetes.

L'extensibilité de Kubernetes via les CRDs (Custom Resource Definitions) a entraîné de nombreuses innovations dans de divers domaines, y compris en CI/ CD. Bien qu'ArgoCD puisse être considéré comme un outil de cette catégorie, il est aujourd'hui spécialisé dans le déploiement sur Kubernetes et ne couvre pas la partie CI (intégration continue).

Nous voyons donc aujourd'hui émerger des outils basés sur Kubernetes qui se rapprochent des moteurs de workflow que nous utilisons/avons utilisé par le passé (e.g. Jenkins) et qui permettent de définir déclarativement des pipelines de CI/CD ou tout autre workflow dont vous auriez besoin.

Nous voyons donc émerger des outils basés sur Kubernetes qui se rapprochent des moteurs de workflow que nous utilisons/ avons utilisé par le passé (e.g. Jenkins), permettant de définir de manière déclarative des pipelines de CI/CD ou tout autre workflow nécessaire.

Nous allons nous intéresser à 2 outils qui n'ont aujourd'hui pas tout à fait la même cible : Tekton et Argo Workflow.

Tekton est une extension (un opérateur) de Kubernetes permettant de définir des workflows via de nouvelles ressources (Task et Pipeline). Il permet également de déclencher ces workflows via n'importe quel type d'événement (EventListener et Trigger). Son intégration simple dans Openshift en fait un outil très utilisé pour la CI/CD et il peut être vu comme le successeur Kubernetes Native de Jenkins.

Argo Workflows, similaire à Tekton, permet d'accomplir à peu près la même chose. Cependant, il est principalement adopté par les équipes effectuant des traitements de données (ETL) ou du machine learning.

Nous ne sommes pas encore convaincus par ces approches pour remplacer les outils intégrés à vos providers git (e.g. Github Actions, Gitlab-CI) du fait de leur adoption déjà établie. Dans le cas où vous disposez d'une infrastructure hétérogène (e.g. VM- Based, Kubernetes etc.) ces outils vous permettront d'homogénéiser votre manière de tester et déployer.

Hold

62Fluxcd

Fluxcd est une solution de CD pour Kubernetes supportant les manifests Helm et Kustomize. Elle permet de déployer en se basant sur une source de configuration comme un dépôt Git.

L’absence d’interface graphique intégrée nativement à Fluxcd est un frein pour le suivi et le debug des déploiements. Son utilisation n’est pas à la portée de tout le monde, il faut bien connaître et comprendre Kubernetes pour pouvoir l’exploiter efficacement.

Pour déployer une seule application, il faut créer au minimum 3 Custom Resources contre une seule avec ArgoCD. Cette complexité augmente le temps pour lire une configuration de ces ressources, mais surtout pour comprendre le fonctionnement global de Fluxcd, ce qui contribue à diminuer l’accessibilité de l’outil.

Le controller de Fluxcd ne fait pas de réconciliation périodique entre lepropose uniquement deux stratégies de réconciliation (chartVersion ou revision) qui met à jour les ressources lors d’un changement de la source (repository ou bucket). Ainsi, le code ne représente plus ce qui est déployé si un administrateur Kubernetes modifie des ressources manuellement. C’est contraire à un principe du GitOps : le code est la source de vérité.

Une solution de GitOps performante doit rendre les développeurs autonomes pour déployer facilement sur les environnements de développements et pour mettre en production. Quand les développeurs gagnent en autonomie, alors les Ops peuvent se concentrer sur des tâches à plus fortes valeurs ajoutées.

Fluxcd est une solution qui fonctionne et qu’on utilise en production chez certains de nos clients. Cependant, nous ne vous recommandons pas de l’installer, nos expériences avec l’outil nous poussant à préférer ArgoCD.

63Jenkins

Jenkins est un orchestrateur de workflows très générique qui permet énormément de flexibilité, mais qui nécessite un gros effort de customisation.

Jenkins est avant tout un orchestrateur de workflows automatisés. Il permet de déclarer des projets dans lesquels il est possible de définir des suites d’actions, que l’on peut ensuite exécuter. Il est également possible de visualiser l’évolution dans le temps de l’état (“success”, “failure”, etc).

L’interface tout comme les mécanismes disponibles pour les workflows sont extrêmement personnalisables via des plugins. Cela vous permettra d’utiliser des variables matricielles pour les actions, d’avoir une météo du projet, des tableaux de bord, voire de pouvoir lancer des scripts généralistes pour réaliser des actions sur vos plateformes de test.

Jenkins s'intègre aussi nativement avec le langage Groovy pour aller plus loin dans la définition des workflows.

Parmi l’ensemble des possibilités, on peut donc en particulier définir des pipelines de CI/CD via notamment des plugins d’intégration avec des gestionnaires de version de code par exemple.

Cependant, les outils CI/ CD spécifiques à certains environnements rendent un outil généraliste comme Jenkins moins attrayant, puisqu'il nécessite sa propre maintenance.

Nous recommandons de privilégier les solutions CI/CD intégrées (ex : GitHub Actions ou GitLab CI). Elles offrent toutes les fonctionnalités nécessaires au développement web moderne, tout en proposant une expérience clé en main.. Cela nécessite beaucoup d’efforts de customisation initiale, mais plus de stabilité à l’usage.