Règles de protection et gouvernance

Les règles de protection disponibles

Sur la page d'un Environment (Settings > Environments > <nom>) :

• Required reviewers — jusqu'à 6 personnes/équipes ; une seule approbation débloque le job.
• Wait timer — un délai en minutes avant que le job ne continue automatiquement, sans action humaine.
• Deployment branches and tags — restreint quelles branches/tags peuvent référencer cet Environment (et donc accéder à ses secrets).
• Prevent administrators from bypassing configured protection rules — désactive le contournement par défaut des admins.

Étape pratique — configurer un reviewer requis et observer le blocage

1. Sur l'Environment demo créé au module précédent, activez Required reviewers et ajoutez-vous vous-même (ou un autre compte si vous en avez un sous la main).
2. Retournez dans l'onglet Actions, relancez le workflow Environment demo (Run workflow).
3. Cette fois, le run reste en statut Waiting au niveau du job say-hello — il ne s'exécute pas immédiatement. Ouvrez le run : un bandeau indique qu'une revue est nécessaire, avec un bouton pour Review deployments.
4. Cliquez dessus, sélectionnez l'Environment concerné, approuvez. Le job reprend et s'exécute normalement.

Vous venez de transformer un déploiement automatique en déploiement gouverné — sans changer une ligne du workflow lui-même, uniquement la configuration de l'Environment qu'il référence.

Étape pratique — restreindre les branches de déploiement

1. Sur le même Environment demo, activez Deployment branches and tags et choisissez Selected branches and tags, en n'autorisant que main.
2. Créez une branche feature/test-env et poussez-y une modification triviale (un commentaire ajouté au workflow, par exemple).
3. Depuis cette branche, tentez de déclencher le workflow Environment demo via workflow_dispatch en sélectionnant feature/test-env comme référence.
4. Observez : le job échoue à démarrer, avec un message indiquant que la branche n'est pas autorisée à déployer sur cet Environment.

Si vous comptez réutiliser cet Environment demo pour autre chose par la suite, retirez maintenant la restriction de branche et/ou le reviewer requis — les modules suivants ne les réutilisent pas, mais autant ne pas laisser votre repo dans un état plus verrouillé que nécessaire sans vous en souvenir.

Pourquoi cette gouvernance compte

Sans règle de protection, un Environment n'est qu'un espace de nommage pour des secrets — utile pour le scoping (module 2), mais sans garde-fou. Avec des reviewers requis et une restriction de branche, vous obtenez une vraie porte de contrôle : personne ne déploie en production depuis une branche non validée, ou sans qu'une personne désignée l'ait explicitement approuvé. C'est ce mécanisme, plus que le scoping de secrets, qui justifie l'essentiel de l'intérêt des Environments — et son coût de configuration (module suivant).

Ce que vous venez de faire

Vous avez configuré et observé, avec de vraies exécutions bloquées puis débloquées, les deux mécanismes de gouvernance les plus utilisés : l'approbation humaine requise et la restriction de branche. Le module suivant prend du recul pour peser objectivement les bénéfices de tout ça face à sa complexité et à son coût réel.