Livraisons : le passage obligé avant un déploiement

Déployer en production d'un simple bouton convient très bien, jusqu'au jour où cela ne convient plus. L'onglet Versions d'une instance propose l'autre voie : un changement devient une livraison, la livraison franchit des étapes, et tout le passage est consigné.

Posons d'abord la limite. Cet onglet prépare un déploiement et s'arrête à prête à déployer. Il ne déploie rien lui-même — cela reste le bouton Déployer de l'environnement, décrit dans le guide sur le déploiement depuis Git. Ce que vous obtenez ici, c'est tout ce qui devrait se passer avant ce clic, et la trace de qui a laissé passer.

La politique décide de tout le reste

Avant que quoi que ce soit ait du sens, il y a une politique de livraison — une par type d'environnement, pas une par environnement. Elle répond à cinq questions, et le reste de l'onglet ne fait qu'y obéir.

Les valeurs par défaut ne sont pas les mêmes partout :

Un environnement est classé d'après sa clé : tout ce qui contient prod compte comme production, stag comme recette, dev comme développement — et tout ce qui n'est pas reconnu est traité comme de la recette, pas comme de la production. Bon à savoir quand on nomme un environnement de façon originale.

Créer une livraison

Une livraison nomme une source, une cible, et le commit qui se déplace. La source est facultative : sans elle, la livraison est manuelle et vous fournissez la branche vous-même. Avec elle, la plateforme retrouve le commit que cet environnement fait réellement tourner — c'est ce qui donne à « passer la recette en production » un sens exact plutôt que « ce qui se trouve sur la branche en ce moment ».

Le titre et la description sont facultatifs eux aussi ; laissez-les vides et la livraison est intitulée d'après les deux environnements.

Les contrôles, et ceux qui peuvent vous arrêter

Lancer les contrôles fait passer la livraison par sept vérifications automatiques. Chacune rend un état — réussi, avertissement, échoué ou ignoré — et, séparément, une gravité.

Ces deux mots ensemble font toute la logique : une livraison n'est bloquée que lorsqu'un contrôle échoué est aussi bloquant. Un contrôle échoué de gravité avertissement n'arrête rien — il est là pour être lu.

Trois des contrôles sont commandés par la politique : dépendances du catalogue, santé de l'environnement et disponibilité d'une sauvegarde. Quand la politique en désactive un, il n'est pas silencieusement omis : il est consigné comme ignoré, avec l'environnement pour lequel il l'a été. Un contrôle qui n'a pas tourné et un contrôle réussi ne doivent jamais se ressembler.

Les approbations, et pourquoi vous ne pouvez pas approuver la vôtre

Si la politique demande des approbations, la livraison s'arrête à en attente d'approbation et rien ne bouge tant qu'une personne n'agit pas.

En production, l'auto-approbation est bloquée par défaut : la personne qui a créé la livraison ne peut pas l'approuver. Essayer se solde par un refus, pas par un silence. Cette seule règle est l'essentiel de ce à quoi sert un processus de livraison : elle place un second regard entre un changement et les clients qui vont le rencontrer.

Un rejet demande une raison. Les approbations sont comptées, et la livraison ne devient approuvée qu'une fois le compte de la politique atteint.

L'étape de sauvegarde

Quand la politique exige une sauvegarde, une livraison approuvée ne passe pas directement à « prête » : elle attend cette sauvegarde. Déclencher la sauvegarde la prend, et la livraison avance une fois celle-ci terminée.

C'est la même mécanique que celle décrite dans le guide des sauvegardes, avec la même réserve sur ce que vaut une copie : une sauvegarde jamais restaurée est une croyance. Ce que la livraison ajoute, c'est que la copie est rattachée à cette livraison — vous pourrez donc dire, plus tard, quelle sauvegarde correspond à quel changement.

Où cela s'arrête, et quoi faire ensuite

Le parcours est le suivant : brouillon → contrôles → bloquée ou en attente d'approbation → approuvée → sauvegarde en cours → prête à déployer. Chaque étape est enregistrée comme une transition avec sa raison, son acteur et son horodatage, et la carte en montre la chaîne. Cet historique est la raison même d'utiliser cet onglet : des mois plus tard, il répond à « qui a approuvé ceci, et qu'ont dit les contrôles » sans que personne ait à s'en souvenir.

À prête à déployer, l'onglet a fait son travail. Déployez depuis l'environnement, puis revenez ici si vous avez besoin de la trace.

Deux autres éléments de la carte méritent d'être connus. Cloner en brouillon recopie une livraison dans un brouillon neuf — le moyen le plus rapide de recommencer après avoir corrigé un bloquant, sans tout ressaisir. Et la politique indique aussi si le retour en arrière et la restauration des données sont autorisés pour cet environnement : les règles sont ainsi écrites au même endroit, même si ces boutons se trouvent ailleurs.

L'onglet Versions exige builds.view pour s'ouvrir. Revenir en arrière sur un déploiement exige deployments.rollback, que le rôle développeur possède et pas un lecteur.