Formation Pipelines CI/CD et déploiement continu
Concevoir et automatiser build, tests et déploiements avec les principales plateformes DevOps, jusqu'aux déploiements progressifs et à GitOps avec ArgoCD
- Durée
- 4 jours
- Niveau
- Intermédiaire
- Modalités
- Distanciel
Description de la formation pipelines CI/CD
Qu'est-ce qu'un pipeline CI/CD ?
Un pipeline CI/CD automatise le chemin du code, du commit jusqu'à la production. Il enchaîne la compilation, les tests, l'analyse de qualité, la création des artefacts et le déploiement dans les différents environnements.
Décrit sous forme de code et versionné avec l'application, il rend les livraisons rapides, fiables et reproductibles. Jenkins, GitLab CI et GitHub Actions sont aujourd'hui les trois moteurs les plus utilisés pour le mettre en œuvre.
Pourquoi suivre une formation Pipelines CI/CD et déploiement continu ?
Les équipes doivent souvent travailler avec plusieurs moteurs de CI/CD, hérités de l'historique ou imposés par les projets. Cette formation apprend à concevoir des pipelines robustes en comparant, sur chaque sujet, les solutions de Jenkins, GitLab CI et GitHub Actions. Les participants construisent le même pipeline sur les trois outils. Ils l'enrichissent ensuite de tests, d'analyses, de conteneurs et de déploiements automatisés, puis vont jusqu'aux déploiements progressifs blue/green et canary et au déploiement GitOps avec ArgoCD. Ils repartent capables de choisir l'outil adapté à leur contexte et d'industrialiser leurs livraisons.
Objectifs pédagogiques
À l'issue de cette formation Pipelines CI/CD et déploiement continu, vous aurez acquis les connaissances nécessaires pour :
- Comprendre les concepts d'intégration, de livraison et de déploiement continus.
- Configurer Jenkins, GitLab CI et GitHub Actions et écrire des pipelines dans chacun des outils.
- Intégrer tests, analyse de qualité, dépôts d'artefacts et conteneurs dans un pipeline.
- Mutualiser et réutiliser le code des pipelines entre projets.
- Mettre en œuvre des déploiements progressifs (blue/green, canary) et une approche GitOps avec ArgoCD.
- Comparer les trois outils pour choisir le plus adapté à chaque contexte.
Objectifs opérationnels
Savoir concevoir et automatiser des pipelines de build, de test et de déploiement avec Jenkins, GitLab CI et GitHub Actions.
Programme
Contenu du cours, module par module
15 modules
- Intégration continue, livraison continue, déploiement continu : définitions et différences
- La chaîne build, release, deploy et la notion de pipeline
- Bénéfices attendus et indicateurs : fréquence de déploiement, délai de mise en production, taux d'échec
- Panorama des moteurs : Jenkins, GitLab CI, GitHub Actions et leur positionnement
Travaux pratiques
Objectif :Situer les pratiques CI/CD dans le cycle de livraison du projet fil rouge.
Description :Les participants découvrent l'application fil rouge et son processus de livraison manuel. En binôme, ils identifient les étapes à automatiser et les classent en intégration, livraison et déploiement. Ils dessinent le pipeline cible qui sera construit pendant la formation. Quelles étapes présentent aujourd'hui le plus de risques d'erreur humaine ? La confrontation des schémas en plénière valide les acquis.
Description :Les participants découvrent l'application fil rouge et son processus de livraison manuel. En binôme, ils identifient les étapes à automatiser et les classent en intégration, livraison et déploiement. Ils dessinent le pipeline cible qui sera construit pendant la formation. Quelles étapes présentent aujourd'hui le plus de risques d'erreur humaine ? La confrontation des schémas en plénière valide les acquis.
- Jenkins : contrôleur, agents, exécuteurs et plugins
- GitLab CI : instance, runners et exécuteurs
- GitHub Actions : runners hébergés et auto-hébergés
- Installation, configuration et sécurisation de base de chaque moteur
Travaux pratiques
Objectif : Préparer les trois environnements d'exécution du projet fil rouge.
Description : Les participants prennent connaissance de l'environnement fourni, découvre les agents Jenkins, les runners GitLab ou GitHub. Ils relient chaque moteur au dépôt du projet fil rouge. Ils comparent l'effort de configuration nécessaire pour chaque outil. Quel modèle d'exécution offre le meilleur contrôle sur l'environnement de build ? Un premier job exécuté sur chaque moteur valide l'exercice.
Description : Les participants prennent connaissance de l'environnement fourni, découvre les agents Jenkins, les runners GitLab ou GitHub. Ils relient chaque moteur au dépôt du projet fil rouge. Ils comparent l'effort de configuration nécessaire pour chaque outil. Quel modèle d'exécution offre le meilleur contrôle sur l'environnement de build ? Un premier job exécuté sur chaque moteur valide l'exercice.
- Jenkinsfile : syntaxe déclarative et syntaxe script
- Fichier .gitlab-ci.yml : stages et jobs
- Workflows GitHub Actions : jobs, steps et actions
- Déclencheurs : push, demande de fusion, planification, déclenchement manuel
- Outils d'aide : linter Jenkins, éditeur de pipeline GitLab, validation des workflows
Travaux pratiques
Objectif : Écrire le même pipeline minimal dans les trois syntaxes.
Description :Les participants écrivent un pipeline de compilation pour le projet fil rouge en Jenkinsfile, puis en .gitlab-ci.yml, puis en workflow GitHub Actions. Ils le déclenchent sur un push et sur une demande de fusion. Ils dressent un tableau de correspondance des notions entre les trois outils. Quelle syntaxe vous paraît la plus lisible pour un nouvel arrivant dans l'équipe ? Les trois pipelines exécutés avec succès valident l'exercice.
Description :Les participants écrivent un pipeline de compilation pour le projet fil rouge en Jenkinsfile, puis en .gitlab-ci.yml, puis en workflow GitHub Actions. Ils le déclenchent sur un push et sur une demande de fusion. Ils dressent un tableau de correspondance des notions entre les trois outils. Quelle syntaxe vous paraît la plus lisible pour un nouvel arrivant dans l'équipe ? Les trois pipelines exécutés avec succès valident l'exercice.
- Récupération du code, compilation et exécution des tests unitaires
- Publication des rapports de tests (format JUnit)
- Statut du pipeline et retour dans la demande de fusion
- Lecture des logs et diagnostic d'échec
Travaux pratiques
Objectif : Construire un pipeline d'intégration continue complet sur les trois moteurs.
Description : Les participants ajoutent l'exécution des tests unitaires et la publication des rapports à leurs trois pipelines. Ils introduisent volontairement un test en échec et analysent les logs pour le corriger. Ils vérifient que le statut remonte dans la demande de fusion. Comment chaque outil rend-il visible un échec de test pour le développeur ? Les trois pipelines au vert après correction valident l'exercice.
Description : Les participants ajoutent l'exécution des tests unitaires et la publication des rapports à leurs trois pipelines. Ils introduisent volontairement un test en échec et analysent les logs pour le corriger. Ils vérifient que le statut remonte dans la demande de fusion. Comment chaque outil rend-il visible un échec de test pour le développeur ? Les trois pipelines au vert après correction valident l'exercice.
- Variables, paramètres et environnement d'exécution
- Exécution conditionnelle : when Jenkins, rules GitLab, if GitHub Actions
- Parallélisme et matrices de build
- Dépendances entre étapes, délais, nouvelles tentatives et gestion des erreurs
Travaux pratiques
Objectif : Maîtriser l'enchaînement et la parallélisation des étapes.
Description : Les participants ajoutent à leurs pipelines une matrice de versions et des étapes exécutées en parallèle. Certaines étapes ne s'exécutent que sur la branche principale. Ils gèrent un échec non bloquant et une nouvelle tentative automatique. Quel gain de temps la parallélisation apporte-t-elle sur le projet fil rouge ? La comparaison des durées d'exécution valide les acquis.
Description : Les participants ajoutent à leurs pipelines une matrice de versions et des étapes exécutées en parallèle. Certaines étapes ne s'exécutent que sur la branche principale. Ils gèrent un échec non bloquant et une nouvelle tentative automatique. Quel gain de temps la parallélisation apporte-t-elle sur le projet fil rouge ? La comparaison des durées d'exécution valide les acquis.
- Stash et archive dans Jenkins
- Cache et artefacts dans GitLab CI
- Cache et artefacts dans GitHub Actions
- Transmettre des données entre étapes et entre pipelines
Travaux pratiques
Objectif : Optimiser les pipelines grâce au cache et aux artefacts.
Description : Les participants mettent en cache les dépendances du projet sur les trois moteurs. Ils transmettent l'artefact compilé de l'étape de build à l'étape de test. Ils mesurent le temps gagné à chaque exécution. Pourquoi faut-il distinguer cache et artefacts ? La comparaison des durées avant et après optimisation valide l'exercice.
Description : Les participants mettent en cache les dépendances du projet sur les trois moteurs. Ils transmettent l'artefact compilé de l'étape de build à l'étape de test. Ils mesurent le temps gagné à chaque exécution. Pourquoi faut-il distinguer cache et artefacts ? La comparaison des durées avant et après optimisation valide l'exercice.
- Les niveaux de tests dans un pipeline : unitaires, intégration, fonctionnels
- Analyse statique et qualité du code avec SonarQube
- Quality gates : bloquer un pipeline sur des critères de qualité
- Intégration des résultats aux demandes de fusion
Travaux pratiques
Objectif : Faire de la qualité un critère bloquant du pipeline.
Description : Les participants intègrent une analyse SonarQube à leurs trois pipelines. Ils configurent une quality gate et vérifient qu'elle bloque le pipeline lorsque le seuil n'est pas atteint. Ils corrigent ensuite le code pour lever le blocage. Quels critères de qualité méritent réellement de bloquer une livraison ? La quality gate franchie après correction valide l'exercice.
Description : Les participants intègrent une analyse SonarQube à leurs trois pipelines. Ils configurent une quality gate et vérifient qu'elle bloque le pipeline lorsque le seuil n'est pas atteint. Ils corrigent ensuite le code pour lever le blocage. Quels critères de qualité méritent réellement de bloquer une livraison ? La quality gate franchie après correction valide l'exercice.
- Versionnement des livrables et processus de release
- Notion de déploiement immuable : construire une fois, déployer partout
- Publication dans un dépôt d'artefacts : Nexus, registres de packages GitLab et GitHub
- Tags, releases et traçabilité du code vers le livrable
Travaux pratiques
Objectif :Automatiser la publication d'un livrable versionné.
Description :Les participants automatisent la création d'une release à partir d'un tag Git. Le livrable est publié dans Nexus depuis Jenkins et dans le registre de packages de GitLab et de GitHub. Ils vérifient la traçabilité entre le tag, le pipeline et l'artefact publié. Comment garantir que l'artefact déployé est exactement celui qui a été testé ? Les trois livrables versionnés et retrouvables valident l'exercice.
Description :Les participants automatisent la création d'une release à partir d'un tag Git. Le livrable est publié dans Nexus depuis Jenkins et dans le registre de packages de GitLab et de GitHub. Ils vérifient la traçabilité entre le tag, le pipeline et l'artefact publié. Comment garantir que l'artefact déployé est exactement celui qui a été testé ? Les trois livrables versionnés et retrouvables valident l'exercice.
- Exécuter les étapes dans des conteneurs : agents Docker Jenkins, images GitLab CI, conteneurs de jobs GitHub Actions
- Construire et publier des images OCI depuis un pipeline
- Agents éphémères dans Kubernetes
- Analyse de vulnérabilités des images
Travaux pratiques
Objectif :Conteneuriser le build et produire l'image du projet fil rouge.
Description :Les participants exécutent leurs étapes de build dans des conteneurs sur les trois moteurs. Ils construisent l'image de l'application, l'analysent puis la publient dans un registre avec un tag de version. Ils configurent un agent Jenkins éphémère dans Kubernetes. Quel avantage apporte l'exécution des builds dans des conteneurs éphémères ? L'image publiée et exécutable valide l'exercice.
Description :Les participants exécutent leurs étapes de build dans des conteneurs sur les trois moteurs. Ils construisent l'image de l'application, l'analysent puis la publient dans un registre avec un tag de version. Ils configurent un agent Jenkins éphémère dans Kubernetes. Quel avantage apporte l'exécution des builds dans des conteneurs éphémères ? L'image publiée et exécutable valide l'exercice.
- Environnements : développement, recette, production
- Déploiement sur Kubernetes depuis le pipeline avec Helm
- Approbation manuelle avant production : input Jenkins, jobs manuels GitLab, environnements protégés GitHub
- Secrets et variables par environnement
- Tests de post-déploiement et retour arrière
Travaux pratiques
Objectif :Mettre en place un déploiement continu multi-environnements.
Description :Les participants déploient automatiquement l'application en recette depuis chacun des trois moteurs. Le passage en production est soumis à une approbation manuelle. Un test de post-déploiement déclenche un retour arrière en cas d'échec. Quels garde-fous faut-il imposer avant chaque mise en production ? Le déploiement validé sur les deux environnements valide l'exercice.
Description :Les participants déploient automatiquement l'application en recette depuis chacun des trois moteurs. Le passage en production est soumis à une approbation manuelle. Un test de post-déploiement déclenche un retour arrière en cas d'échec. Quels garde-fous faut-il imposer avant chaque mise en production ? Le déploiement validé sur les deux environnements valide l'exercice.
- Librairies partagées Jenkins : structure, variables globales, pipelines configurables
- GitLab CI : include, templates et composants CI/CD
- GitHub Actions : workflows réutilisables et actions composites
- Gouvernance des pipelines communs à plusieurs projets
Travaux pratiques
Objectif :Factoriser le pipeline du projet fil rouge pour le réutiliser.
Description :Les participants extraient les étapes communes de leurs pipelines dans une librairie partagée Jenkins, un composant GitLab et un workflow réutilisable GitHub. Ils appliquent le pipeline mutualisé à un second projet. Ils comparent l'effort de maintenance de chaque approche. Quelle solution de mutualisation est la plus simple à faire évoluer ? Le second projet automatisé sans duplication valide l'exercice.
Description :Les participants extraient les étapes communes de leurs pipelines dans une librairie partagée Jenkins, un composant GitLab et un workflow réutilisable GitHub. Ils appliquent le pipeline mutualisé à un second projet. Ils comparent l'effort de maintenance de chaque approche. Quelle solution de mutualisation est la plus simple à faire évoluer ? Le second projet automatisé sans duplication valide l'exercice.
- Déploiement recreate, rolling update, blue/green, canary : principes et compromis
- Feature flags et dissociation entre déploiement et mise en service
- Indicateurs de santé et critères de promotion ou de retour arrière
- Mise en œuvre d'un blue/green et d'un canary depuis un pipeline
Travaux pratiques
Objectif :Mettre en œuvre un déploiement blue/green puis canary.
Description :Les participants déploient une nouvelle version de l'application en blue/green, puis basculent le trafic. Ils réalisent ensuite un déploiement canary en exposant progressivement la nouvelle version. Une version défectueuse est volontairement introduite pour déclencher un retour arrière. Quelle stratégie choisir pour une application critique à fort trafic ? Le retour arrière réussi valide l'exercice.
Description :Les participants déploient une nouvelle version de l'application en blue/green, puis basculent le trafic. Ils réalisent ensuite un déploiement canary en exposant progressivement la nouvelle version. Une version défectueuse est volontairement introduite pour déclencher un retour arrière. Quelle stratégie choisir pour une application critique à fort trafic ? Le retour arrière réussi valide l'exercice.
- Architecture et ressource Rollout
- Étapes canary, pauses et promotion
- Analyse automatique des métriques et retour arrière automatique
- Blue/green avec Argo Rollouts
Travaux pratiques
Objectif :Automatiser la promotion d'une version selon ses métriques.
Description :Les participants convertissent le déploiement de l'application en ressource Rollout. Ils définissent des étapes canary progressives et une analyse automatique basée sur le taux d'erreur. Une version défectueuse est déployée et doit être annulée sans intervention. Quels indicateurs retenir pour décider automatiquement d'une promotion ? Le retour arrière automatique observé valide l'exercice.
Description :Les participants convertissent le déploiement de l'application en ressource Rollout. Ils définissent des étapes canary progressives et une analyse automatique basée sur le taux d'erreur. Une version défectueuse est déployée et doit être annulée sans intervention. Quels indicateurs retenir pour décider automatiquement d'une promotion ? Le retour arrière automatique observé valide l'exercice.
- Principes GitOps : Git comme source de vérité, modèle pull contre modèle push
- Architecture d'ArgoCD et ressource Application
- Synchronisation manuelle ou automatique, détection des dérives, retour arrière
- Projets, droits d'accès et gestion multi-environnements
- Alternatives : Flux et agent Kubernetes de GitLab
Travaux pratiques
Objectif :Déployer l'application en mode GitOps avec ArgoCD.
Description :Les participants créent un dépôt de configuration contenant les manifestes de l'application. Ils déclarent l'application dans ArgoCD et activent la synchronisation automatique. Ils provoquent une modification manuelle du cluster et observent la correction de la dérive. En quoi le modèle pull de GitOps renforce-t-il la sécurité des déploiements ? Le retour à l'état déclaré dans Git valide l'exercice.
Description :Les participants créent un dépôt de configuration contenant les manifestes de l'application. Ils déclarent l'application dans ArgoCD et activent la synchronisation automatique. Ils provoquent une modification manuelle du cluster et observent la correction de la dérive. En quoi le modèle pull de GitOps renforce-t-il la sécurité des déploiements ? Le retour à l'état déclaré dans Git valide l'exercice.
- Articuler pipeline CI et déploiement GitOps : mise à jour automatique du dépôt de configuration
- Jenkins, GitLab CI et GitHub Actions comme pipelines CI en amont d'ArgoCD
- Promotion entre environnements par demande de fusion
- Critères de choix entre les trois outils selon le contexte
Travaux pratiques
Objectif :Assembler une chaîne de livraison complète, du commit à la production.
Description :Les participants relient leur pipeline CI au dépôt de configuration ArgoCD, sur le moteur de leur choix. Un commit applicatif produit une image, met à jour la configuration et déclenche un déploiement canary. La promotion en production passe par une demande de fusion. Quel moteur choisiriez-vous pour votre propre contexte, et pourquoi ? La chaîne exécutée de bout en bout et la grille comparative complétée clôturent la formation.
Description :Les participants relient leur pipeline CI au dépôt de configuration ArgoCD, sur le moteur de leur choix. Un commit applicatif produit une image, met à jour la configuration et déclenche un déploiement canary. La promotion en production passe par une demande de fusion. Quel moteur choisiriez-vous pour votre propre contexte, et pourquoi ? La chaîne exécutée de bout en bout et la grille comparative complétée clôturent la formation.
Travaux pratiques
Un même projet fil rouge est automatisé successivement sur Jenkins, GitLab CI et GitHub Actions. Les TP utilisent Docker, SonarQube, un dépôt d'artefacts, un cluster Kubernetes, ArgoCD et Argo Rollouts. Environ 60 % du temps est consacré aux travaux pratiques.
Programme mis à jour le 09/11/2026
Public concerné
Développeurs, ingénieurs DevOps et chefs de projet applicatif souhaitant concevoir et automatiser des chaînes de livraison continue.
Prérequis
La maîtrise des bases de Git (commit, branches, fusion, dépôt distant) est nécessaire, car tous les pipelines de la formation sont déclenchés et versionnés depuis Git. Des notions sur les conteneurs Docker facilitent la prise en main des journées 3 et 4, mais elles ne sont pas exigées : les commandes et concepts utiles sont rappelés en séance.
J’évalue mes connaissances pour vérifier que je dispose des prérequis nécessaires pour profiter pleinement de cette formation en faisant le test de prérequis.
Faire le testFinancement
Cette formation peut être prise en charge par votre entreprise, seule ou avec l’appui de son opérateur de compétences. Nous fournissons le devis et les pièces attendues par l’OPCO.