Construire une fois, promouvoir par digest : un pipeline de livraison réversible
Un chemin de livraison de référence où l'artefact testé en staging est exactement celui de la production, et où un rollback consiste à redéployer le digest précédent.
Les exemples sont génériques et illustratifs. Ils ne proviennent d'aucun environnement client : adaptez seuils et réglages à votre propre système.
Le problème de la reconstruction par environnement
Les pipelines qui reconstruisent l'application pour chaque environnement testent un artefact et en livrent un autre. Les dépendances se résolvent autrement, une image de base évolue, un flag de compilation diffère — et la version en production n'a été testée nulle part. Construisez une fois, donnez à l'artefact une identité immuable et promouvez cette identité.
Chemin de référence
Un chemin générique du commit à la production. Chaque étape transmet le même artefact ou l'arrête.
- 01CommitPull request avec relecture et vérifications obligatoires.
- 02BuildUn build par commit ; l'image est publiée et son digest enregistré.
- 03VérificationTests, analyse des dépendances et de l'image, signature.
- 04StagingLe digest est déployé ; tests de fumée et d'intégration.
- 05ProductionLe même digest, déployé progressivement.
- 06ObservationBudget d'erreur et alertes décident : continuer ou revenir en arrière.
Des digests, pas des tags
Des tags comme latest ou v2 sont des étiquettes mutables ; un digest (sha256:…) est l'empreinte du contenu de l'image. Les manifestes de déploiement doivent référencer le digest, et le pipeline promeut un environnement en changeant cette seule valeur — idéalement par un commit dans le dépôt de déploiement, pour que chaque release soit un changement relu et réversible.
# build once and record the digest
docker buildx build --push --metadata-file meta.json \
-t registry.example.com/api:"$GIT_SHA" .
DIGEST=$(jq -r '."containerimage.digest"' meta.json)
# promote: every environment receives the same digest
kustomize edit set image api=registry.example.com/api@"$DIGEST"Changements de base de données : étendre, puis contracter
Revenir en arrière sur le code n'est facile que si le schéma convient encore à la version précédente. Découpez les migrations incompatibles en étapes compatibles avec le code en service : ajoutez la nouvelle colonne ou table, déployez un code qui écrit dans les deux, remplissez les données, basculez les lectures, et ne supprimez l'ancienne structure que dans une release ultérieure.
Livraison progressive et rollback
- Déployez d'abord sur une fraction du trafic ou des réplicas, et comparez le taux d'erreur et la latence avec la version actuelle.
- Liez la décision au SLO : un taux de consommation élevé pendant le déploiement arrête automatiquement la promotion.
- Un rollback, c'est redéployer le digest précédent — le même chemin, déjà testé — et non un correctif écrit sous pression.
- Gardez la configuration et les secrets hors de l'image, pour que le même artefact tourne dans tous les environnements.