← Retour à l'accueil

Cours 04

De l'artefact à la production — Continuous Delivery et Continuous Deployment

Le cours-03 a posé les flows de développement et les bases d'une CI lisible, fail-fast et exécutable localement. Cette séance répond à la question suivante : quand le code est validé, comment le transformer en livrable versionné, publié et prêt à partir vers un environnement ?

QCM de reprise du cours-03

La séance commence par 20 minutes de QCM sur papier ; posez le stylo quand le temps est écoulé.

CI vers CD : le chaînon manquant

La CI répond à « est-ce que ce changement reste sain ? ». La CD commence quand la question devient : « quel livrable exact doit être transmis à la suite ? ». Le passage critique est donc l'artefact : une sortie de pipeline versionnée, traçable et réutilisable.

CI

Valide le changement : formatage, lint, tests, build, sécurité.

Continuous Delivery

Prépare et publie un livrable prêt à déployer. Le dernier choix reste humain.

Continuous Deployment

Déploie automatiquement chaque changement validé sur la branche principale.

Repère : la Delivery n'est pas un Deployment incomplet. C'est un niveau de maturité utile quand l'équipe veut des livrables fiables tout en gardant une décision humaine sur le moment de mise en production.

CD as Continuous Delivery

La Continuous Delivery est étudiée avec un GitHub Flow concret : branche courte, Pull Request, CI, rebase sur main, intégration fast-forward, versioning, puis publication d'artefacts. La chaîne s'arrête volontairement après la publication : tout est prêt, mais rien n'est automatiquement envoyé en production.

Chargement du flowchart…

Build once, publish many : la pipeline compile une seule fois le code validé, conserve le résultat comme artefact, puis réutilise exactement ce même contenu pour produire plusieurs livrables. L'intérêt est double : si un test a validé le build, les publications partent de ce build, et en cas d'incident, le commit, la version et l'artefact publiés restent identifiables. Recompiler séparément pour chaque format créerait plusieurs sorties supposées identiques, mais difficiles à prouver identiques.

Ce principe ne désigne pas un type d'artefact particulier. Il décrit une règle de pipeline : une sortie de build fiable devient la source commune des publications. Les formats ci-dessous sont donc des destinations équivalentes possibles, choisies selon la manière dont le logiciel sera consommé ou déployé.

Les cibles de publication :

Packages d'écosystème

Un package npm, Maven, NuGet ou une Python wheel distribue une bibliothèque ou une application dans l'écosystème de son langage. Il est consommé par d'autres projets, par un serveur interne, ou par une étape de livraison qui sait installer ce format.

Images de conteneurs compatibles OCI

OCI signifie Open Container Initiative. C'est un ensemble de spécifications ouvertes qui décrit le format des images de conteneurs et leur distribution via des registres. Une image compatible OCI peut être produite avec Docker et exécutée ou stockée par des outils compatibles.

Binaires et paquets système

Un exécutable, une archive, un paquet .deb ou .rpm reste utile pour les machines virtuelles, les serveurs traditionnels ou les distributions internes. Le format change, mais l'exigence reste la même : publier un livrable versionné, traçable et reproductible.

Verdaccio

Dans le TP, Verdaccio simule un registre npm privé local. Il reçoit le package tp-cd-delivery publié par la pipeline.

registry:2

Le registre Docker officiel local reçoit l'image localhost:5000/tp-cd-delivery:<version>.

Dépôt CD pédagogique I : Continuous Delivery

Dépôt support : GVI2026/tp-cd-delivery. Comme pour les TP précédents, le dépôt doit d'abord être forké sur GitHub, puis cloné localement. La Delivery vient d'être expliquée avec l'exemple du GitHub Flow, mais ce TP n'a plus pour objectif de faire pratiquer un workflow précis : il isole la livraison d'artefacts. La base reprend le dépôt CI, l'allège avec SQLite, puis ajoute deux registres locaux pour publier un package npm et une image Docker.

  1. Sur main, compléter progressivement le job release avec commit-and-tag-version.
  2. Ajouter publish-npm pour publier le build dans Verdaccio, sans recompiler.
  3. Ajouter publish-docker pour pousser l'image vers localhost:5000.
  4. Tester chaque étape avec act, et nettoyer les registres locaux si une version déjà publiée bloque un nouvel essai.
  5. Lancer ensuite npx commit-and-tag-version localement, puis vérifier qu'un nouveau changement applicatif peut repartir d'un dépôt aligné. 
curl http://localhost:4873/-/ping
curl http://localhost:5000/v2/
act -j security
act -j release
act -j publish-npm
act -j publish-docker

Point de vigilance : avec act, les runners sont éphémères. Un tag ou un commit de release créé par npx commit-and-tag-version sert à comprendre la mécanique, mais il ne remonte pas automatiquement dans le dépôt local. Pour ajouter du code après un essai de release, la commande npx commit-and-tag-version doit être lancée localement dans le DevContainer afin de réaligner package.json, CHANGELOG.md et les tags locaux.

Retour sur le TP : les nouveaux jobs de CD

Une fois le TP réalisé, la pipeline est relue comme une chaîne de livraison. La CI prouve que le changement est sain ; les jobs CD donnent une identité au livrable, puis le publient dans des registres locaux.

release

Le job dépend de security avec needs : il ne démarre que si toute la CI précédente a terminé. Il est limité à main avec if: github.ref == 'refs/heads/main', récupère l'historique Git complet, puis laisse commit-and-tag-version calculer la version, mettre à jour les fichiers de release et créer le tag.

publish-npm

Le job récupère l'artefact build-dist produit par build. Il publie donc le résultat déjà compilé dans Verdaccio. Verdaccio refuse une deuxième publication de la même version, ce qui rend visible l'immutabilité attendue d'un package publié.

publish-docker

Le job réutilise le même build-dist, construit une image et la pousse dans registry:2. Un tag Docker étant mutable par défaut, le TP ajoute une vérification avant le push pour éviter de masquer une image déjà publiée.

Limite de la simulation : act lance les jobs dans des conteneurs locaux éphémères. C'est excellent pour comprendre et tester la pipeline, mais un commit de release créé dans le runner n'est pas recopié dans le dépôt du DevContainer. Cette différence explique pourquoi le TP demande ensuite un npx commit-and-tag-version local. Dans un dépôt GitHub réel, ce problème est justement pris en charge par des outils plus intégrés : Release Please prépare une Pull Request de release, tandis que Semantic Release automatise la release directement depuis la pipeline.

SemVer, Conventional Commits et outillage de release

SemVer et Conventional Commits sont considérés comme acquis ; ils sont utilisés ici comme entrée lisible par des outils de release.

Release Please analyse l'historique Git, prépare le changelog, propose le bump de version et matérialise le tout dans une Pull Request de release. L'équipe garde donc un point de contrôle explicite avant la publication. Documentation : github.com/googleapis/release-please.

Semantic Release pousse l'automatisation plus loin : après une CI verte sur la branche de release, il détermine la prochaine version, génère les notes, crée le tag et peut publier les artefacts via plugins. Il convient bien aux équipes qui veulent une release entièrement pilotée par la pipeline. Documentation : semantic-release.gitbook.io/semantic-release.

Quel outil convient à un GitHub Flow qui garde une validation humaine avant release ?

Release Please colle bien à ce besoin : les commits alimentent une Pull Request de release, l'équipe relit le changelog et le bump, puis la publication part après merge.

Quel outil correspond le mieux à un Trunk-Based Workflow très automatisé ?

Semantic Release est plus naturel quand main est toujours déployable : une CI verte suffit à calculer la version, créer le tag et déclencher la publication.

CD as Continuous Deployment

Le Continuous Deployment supprime la dernière validation humaine : un changement intégré sur main, s'il passe toutes les vérifications, part automatiquement vers l'environnement cible. Le flow naturel associé est le Trunk-Based Development : petits lots, intégration fréquente, branche principale toujours verte.

Chargement du flowchart…

Feature flags : ils permettent de déployer du code sans rendre la fonctionnalité immédiatement visible. Le déploiement technique et la mise à disposition utilisateur deviennent deux décisions distinctes.

SSH comme mécanisme de déploiement : pour comprendre le principe, un serveur cible accessible en SSH suffit : copier ou installer l'artefact, redémarrer le service, lancer un smoke test, puis revenir en arrière si le test échoue.

Préconditions : tests fiables, observabilité, alerting, rollback, responsabilité partagée et gestion explicite des incidents. Automatiser sans ces garde-fous revient à accélérer aussi les problèmes.

Le point de bascule est simple à formuler et difficile à tenir : si main part automatiquement vers un environnement, alors main doit rester petit, fréquent, observable et réversible. C'est exactement le terrain du Trunk-Based Development.

Dépôt CD pédagogique II : Continuous Deployment avec le Trunk-Based Development

Dépôt support : GVI2026/tp-cd-deployment. Le dépôt doit être forké avant le travail. Cette fois, la pipeline de Continuous Delivery est déjà en place : release, publication npm et publication Docker. L'objectif est d'ajouter la dernière étape, le Continuous Deployment.

  1. Ajouter deploy-npm pour installer le package depuis Verdaccio sur une cible SSH et le redémarrer avec pm2.
  2. Ajouter deploy-docker pour récupérer l'image publiée dans registry:2 et la lancer dans un second environnement Docker accessible en SSH.
  3. Terminer par healthcheck-deployment, qui vérifie le serveur Node déployé et le conteneur Docker déployé.
  4. Ajouter une petite fonctionnalité GET /tasks/summary protégée par un feature flag volontairement en dur dans le code.
  5. Ajouter enfin un rollback automatique simple si la vérification de déploiement échoue. 
curl http://localhost:4873/-/ping
curl http://localhost:5000/v2/
ssh -p 2222 deployer@localhost "echo ok"
ssh -p 2223 deployer@localhost "echo ok"
act -j publish-npm
act -j publish-docker
act -j healthcheck-deployment

Repère : les deux artefacts sont volontairement déployés dans deux cibles séparées. Le TP montre qu'une même version peut exister comme package npm et comme image OCI, mais que chaque format implique un geste de déploiement, un redémarrage et une vérification adaptés.

Retour sur le TP : les derniers jobs de CD

Les jobs précédents produisaient des artefacts prêts. Les derniers jobs changent la nature de la chaîne : la pipeline agit maintenant sur des environnements vivants, puis doit prouver que le résultat fonctionne.

deploy-npm

Le job consomme le package publié dans Verdaccio, l'installe sur la cible SSH npm, puis redémarre le processus avec pm2. L'application n'est pas reconstruite : la version publiée est déployée telle quelle.

deploy-docker

Le job consomme l'image publiée dans registry:2, remplace le conteneur applicatif sur une seconde cible SSH et garde le format conteneur de bout en bout.

healthcheck-deployment

Le job dépend des deux déploiements et vérifie les endpoints /health. Il matérialise le contrat minimal du Continuous Deployment : la pipeline ne s'arrête pas au redémarrage, elle vérifie que le service répond.

Quelles étapes peuvent compléter la vérification du déploiement ?

Après un healthcheck réussi, la pipeline peut envoyer un message dans un canal de discussion ou par mail pour rendre le déploiement visible. Elle peut aussi clôturer une demande de changement dans un outil ITSM, mettre à jour une documentation de version, publier des notes de release ou enrichir un journal d'audit. Le healthcheck dit « le service répond » ; ces étapes disent « l'organisation sait ce qui vient de partir et peut en garder la trace ».

Mesurer pour progresser : les métriques DORA

Après avoir parcouru les concepts, les flows et les outils nécessaires à une pipeline CI/CD, il reste une question de pilotage : comment mesurer l'impact réel de cette chaîne et justifier les prochains chantiers d'amélioration ? DORA signifie DevOps Research and Assessment, un programme de recherche qui a popularisé des indicateurs de performance de livraison logicielle.

Débit

Change Lead Time : temps entre commit et production.

Deployment Frequency : fréquence des déploiements.

Failed Deployment Recovery Time : temps de retour à un état stable après déploiement raté.

Instabilité

Change Fail Rate : part des déploiements nécessitant rollback, hotfix ou intervention immédiate.

Deployment Rework Rate : part des déploiements non planifiés causés par un incident de production.

Les métriques DORA ne servent pas à mettre les équipes en compétition. Elles servent à formuler des hypothèses, trouver le goulot actuel, agir, puis vérifier si la situation s'améliore.

Lead Time haut + Change Fail Rate haut : que conclure ?

L'équipe livre lentement et casse souvent. Il faut réduire la taille des changements, limiter le WIP, renforcer les tests et améliorer la relecture avant de chercher à accélérer.

Deployment Frequency bas + Change Fail Rate bas : que conclure ?

La qualité semble maîtrisée, mais le processus freine la sortie. Les bons chantiers sont l'automatisation release/publish, des lots plus petits et moins de validations manuelles redondantes.

Failed Deployment Recovery Time haut + Change Fail Rate bas : que conclure ?

Les incidents sont rares, mais l'équipe récupère mal. Il faut travailler rollback, runbooks, smoke tests, alerting et accès aux logs plutôt que seulement ajouter des tests avant déploiement.

Deployment Rework Rate haut + Deployment Frequency haut : que conclure ?

La cadence est là, mais beaucoup de livraisons corrigent des incidents non planifiés. Il faut améliorer l'analyse d'incidents, durcir les contrôles pré-production et suivre les causes de hotfix.

Pour aller plus loin : DORA's software delivery performance metrics.

Synthèse finale

Le module a suivi une progression volontairement continue : versionner le code avec Git, organiser le travail d'équipe avec des flows, automatiser les vérifications avec la CI, puis publier et déployer des artefacts avec la CD.

À la fin de cette progression, un changement de code peut devenir une version identifiable, testée, publiée dans des registres, déployée sur des environnements cibles et vérifiée automatiquement.

Chargement de la pipeline finale…