Faire progresser un même build à travers les environnements : promotion de configuration et parité dev-prod

Objectif

Chaque environnement exécute un artefact construit une seule et unique fois, de sorte qu'un échec en production ne puisse pas s'expliquer par un compilateur différent, une résolution de dépendances différente ou un indicateur de build différent, et que chaque différence entre environnements soit une valeur de configuration explicite.

Prérequis

Un build qui produit un artefact immuable (image de conteneur référencée par digest, paquet versionné) et un runtime qui lit la configuration depuis l'environnement ou des fichiers montés, conformément à la séparation de la configuration et du code prônée par les twelve factors (cité).

Étapes

1. Construire une seule fois par commit en CI et publier l'artefact sous une identité qui n'est jamais réécrite ; consigner le digest ou la somme de contrôle.
2. Définir la release comme artefact plus configuration : selon le facteur build-release-run cité, une release combine le build avec la configuration du déploiement et devrait porter un identifiant de release unique ; il faut donc versionner les fichiers de configuration d'environnement et nommer chaque déploiement artifact@digest + config@revision.
3. Limiter la configuration propre à chaque environnement aux valeurs qui doivent réellement différer : points de terminaison, identifiants, capacité, valeurs par défaut des bascules de fonctionnalités. Toute autre différence constitue un écart de parité à éliminer.
4. Faire progresser en retaguant ou en référençant à nouveau le même artefact, jamais en reconstruisant depuis la même branche ; une reconstruction est un build différent tant que l'identité n'est pas prouvée.
5. Aligner les services annexes (backing services) : le facteur de parité dev/prod (cité) demande de garder le développement, la préproduction et la production aussi semblables que possible en temps (déployer peu après l'écriture), en personnel (les développeurs déploient) et en outils (les mêmes services annexes plutôt que des substituts locaux allégés) ; le facteur avertit que même de petites incompatibilités entre services annexes peuvent faire échouer en production du code qui passait en développement. Exécuter le même moteur et la même version dans Compose en local et en CI.
6. Conditionner chaque promotion à des vérifications qui ont tourné contre cet artefact dans l'environnement précédent, et conserver un registre indiquant quel artefact est actif à quel endroit.
7. Comparer périodiquement la configuration entre environnements et expliquer chaque ligne qui diffère.

Résultat attendu

« Ça marchait en préproduction » devient une affirmation solide, car la préproduction a exécuté les mêmes octets avec une configuration qui ne diffère que sur des valeurs répertoriées. Le rollback est une promotion de l'artefact précédent, pas une reconstruction.

Limites et base de vérification

La parité de volume de données, de forme de trafic et de bacs à sable tiers est rarement atteignable ; la promotion supprime la variance de build, pas la variance environnementale. Les valeurs de configuration qui modifient des chemins de code (bascules) réintroduisent des combinaisons non testées et doivent être traitées comme faisant partie de la release. Les recommandations suivent les facteurs cités ; aucune mesure n'est revendiquée.