Promouvoir l'image, pas la branche
Beaucoup de processus de release portent un mensonge discret : la QA valide un artefact, et la production en reconstruit un autre depuis le même commit, en espérant que la chaîne de build se comporte deux fois pareil. La plupart des jours, oui. Le jour où non, vous livrez une chose que personne n'a testée.
Reconstruire et espérer n'est pas une stratégie
Une reconstruction, c'est une seconde exécution de tout ce qui peut dériver : images de base, résolution de dépendances, arguments de build, le builder lui-même. Le commit est le même, les octets ne sont pas garantis de l'être. Si votre processus reconstruit pour la production, votre couverture de test réelle de ce qui part est exactement nulle.
La forme qui supprime le mensonge
Nous tenons deux branches longues. Develop reçoit les merge requests, déploie en QA, et passe les health checks. Main est la ligne de production, et aucune fonctionnalité n'y fusionne directement. Une release est tag-first : un tag annoté se pose sur le commit validé en QA, puis main avance sur ce commit exact, pour que le tag et la branche racontent la même histoire.
L'artefact suit la même règle. Le job de release récupère l'image QA depuis le registre, la retague avec la version de production, et la repousse. Aucune reconstruction de production n'existe. Les octets qui ont mûri en QA sont, octet pour octet, ceux que la production exécute, sous un nouveau nom immuable.
Des hotfixes sans commits orphelins
Les correctifs urgents partent de main, se déploient en QA pour validation comme tout le reste, et refusionnent dans develop une fois posés. Cette dernière étape est celle que la plupart des équipes sautent, et c'est ainsi que la production accumule des commits qui n'existent nulle part ailleurs, en attendant d'être défaits en silence par la release suivante.
Ce qui change au quotidien
Les approbateurs approuvent un artefact précis, pas une promesse. Les opérateurs répondent à « qu'est-ce qui tourne en prod » avec un tag qui ne veut dire qu'une chose. Et la conversation de release rétrécit, parce que « a-t-on testé ce qu'on a livré » cesse d'être une question.
Des releases à réponse unique
Nous construisons cela en composants de pipeline réutilisables : releases tag-first, promotion d'image, lignes de hotfix validées en QA. Si votre prod reconstruit en espérant, racontez-nous vos releases.
Contactez-nous
flochai