Déployer en production avec des étapes d’approbation

Le déploiement continu livre automatiquement le code, mais l’envoyer directement en production sans aucun point de contrôle est risqué. Une version défectueuse peut affecter instantanément tous les utilisateurs.

Une garde d’approbation est une pause délibérée pendant laquelle une personne (ou une vérification automatisée) confirme qu’un déploiement peut continuer.

• Réduit l’ampleur des conséquences des erreurs
• Crée une piste d’audit indiquant qui a approuvé quoi
• Permet de distinguer les niveaux de confiance de la staging et de la production

GitHub Actions propose une fonctionnalité appelée Environnements. Un environnement, comme production, peut posséder ses propres secrets, variables et règles de protection.

Vous référencez un environnement depuis une tâche à l’aide de la clé environment. C’est la base pour ajouter des gardes d’approbation.

Dans les paramètres du dépôt, sous Paramètres > Environnements > production, vous pouvez activer les approbateurs requis.

Lorsqu’une tâche cible cet environnement, l’exécution du flux de travail se met en pause et attend qu’un des approbateurs répertoriés clique sur Approve.

• Jusqu’à 6 approbateurs peuvent être configurés
• Une seule approbation suffit par défaut à débloquer la tâche
• Selon les paramètres, l’approbateur ne peut pas être la personne qui a déclenché l’exécution

Ici, une tâche de build s’exécute d’abord, puis une tâche de deploy en dépend via needs et cible l’environnement protégé production.

Le déploiement ne démarrera pas tant que l’approbateur requis ne l’aura pas approuvé dans l’interface Actions.

En plus des approbateurs, les environnements prennent en charge un temporisateur d’attente. Celui-ci impose un délai, pouvant aller jusqu’à 30 jours, avant qu’un déploiement puisse continuer.

Un court délai d’attente est utile comme période de refroidissement de sécurité : il donne à l’équipe le temps d’annuler une exécution avant qu’elle n’atteigne la production.

Les environnements peuvent limiter les branches autorisées à déployer. Pour production, vous n’autorisez généralement que main (ou les balises de version).

Cela empêche un déploiement accidentel en production depuis une branche de fonctionnalité.

• Branches protégées — uniquement les branches dotées de règles de protection
• Branches sélectionnées — une liste d’autorisation explicite ou un modèle de balise

Chaque environnement possède ses propres secrets. Un environnement production peut contenir PROD_DB_URL, tandis que staging contient STAGING_DB_URL.

Les secrets définis au niveau de l’environnement ne sont disponibles que pour les tâches qui ciblent cet environnement, ce qui ajoute une couche d’isolation.

La définition d’une url sur l’environnement ajoute un lien cliquable vers le déploiement dans l’interface GitHub et enregistre un objet de déploiement via l’API des déploiements.

Vous disposez ainsi d’un historique visible : quelle validation a été déployée en production, à quel moment et par qui.

Lorsqu’une tâche protégée est en attente, une bannière jaune Examiner les déploiements s’affiche sur la page de l’exécution du flux de travail.

• Ouvrez l’exécution dans l’onglet Actions
• Cliquez sur Review deployments
• Sélectionnez l’environnement et cliquez sur Approve and deploy ou Reject

Vous pouvez également laisser un commentaire expliquant votre décision.

La garde de production la plus solide combine plusieurs règles :

• Approbateurs requis (approbation humaine)
• Un temporisateur d’attente (délai de sécurité)
• Des restrictions de branche (uniquement main)
• Des secrets d’environnement (isolation)

La combinaison de ces éléments crée un processus robuste de promotion de la préproduction vers la production.

Vous pouvez parfois avoir besoin d’un correctif urgent. Plutôt que de supprimer les règles de protection, envisagez un flux de travail de correctif urgent distinct et strictement limité, avec sa propre journalisation et des exigences de revue plus strictes.

Ne désactivez jamais définitivement les gardes par commodité : cela annulerait l’objectif du mécanisme de sécurité.

Vérifiez votre compréhension des gardes d’approbation de production.

Vous avez appris à ajouter des gardes d’approbation aux déploiements en production à l’aide des environnements GitHub.

• Utilisez la clé environment pour cibler un environnement protégé
• Les approbateurs requis ajoutent une approbation humaine
• Les temporisateurs d’attente ajoutent une période de refroidissement
• Les restrictions de branche et les secrets d’environnement ajoutent une isolation

Ensemble, ces gardes rendent la promotion de la préproduction vers la production sûre et vérifiable.