infra / github-actions
Environments et approbations
Explication
Ce que vous allez apprendre
- Comprendre pourquoi un déploiement en production mérite plus de garde-fous qu'un déploiement de test
- Configurer un
environmentexigeant une approbation manuelle avant exécution - Restreindre les branches autorisées à déployer vers un environment donné
- Isoler des secrets propres à un environment, inaccessibles aux jobs qui ne le déclarent pas
- Enchaîner un schéma à deux étages : staging automatique, puis production approuvée
Dans quel contexte ?
Une équipe a un seul pipeline de déploiement qui pousse automatiquement en production à chaque merge sur main, sans aucune étape intermédiaire. Un vendredi, une pull request contenant un bug critique est mergée par erreur, et se retrouve en production trois minutes plus tard, avant que quiconque n'ait eu le temps de la relire une dernière fois. Les environments GitHub Actions existent pour ce cas précis : ajouter un vrai point de contrôle humain avant qu'un changement n'atteigne les utilisateurs réels.
Le problème : tous les déploiements ne se valent pas
D'abord, déployer sur un environnement de test peut se faire automatiquement, sans y réfléchir à deux fois.
Un cas différent : la production
Déployer en production est une décision différente : une erreur y a un impact réel sur les utilisateurs.
Le risque de traiter les deux pareil
Un pipeline qui traite les deux de la même façon, automatiquement, sans garde-fou, prend un risque disproportionné pour ce second cas.
Ce qu'un environment ajoute concrètement
Un environment est une couche de règles qu'on associe à un job : il peut exiger qu'une ou plusieurs personnes approuvent manuellement avant que le job ne s'exécute réellement.
| Règle d'environment | Effet |
|---|---|
| Reviewers requis | Le job attend une approbation manuelle avant de s'exécuter |
Délai d'attente (wait timer) | Laisse un temps de réflexion avant l'exécution |
| Branches autorisées | Restreint depuis quelles branches un déploiement peut partir |
| Secrets d'environment | Accessibles uniquement aux jobs qui déclarent cet environment |
D'autres règles possibles
Il peut aussi imposer un délai d'attente obligatoire, le temps de changer d'avis avant que ça parte, ou restreindre depuis quelles branches un déploiement est autorisé.
Prérequis
Cette leçon s'appuie directement sur les secrets vus à la leçon précédente : un secret d'environment fonctionne comme un secret de dépôt, mais avec une portée encore plus restreinte.
Le lien avec les secrets vus à la leçon précédente
Un environment peut aussi porter ses propres secrets, accessibles uniquement aux jobs qui déclarent explicitement cet environment.
Piège fréquent
Même un autre job du même workflow, s'il ne référence pas explicitement cet environment, ne peut PAS lire ses secrets. Oublier de déclarer environment: production sur un job qui en a réellement besoin provoque une erreur d'accès au secret, souvent surprenante à diagnostiquer la première fois.
La portée la plus restrictive possible
Même un autre job du même workflow, s'il ne référence pas cet environment, ne peut pas lire ces secrets, un cloisonnement précieux pour séparer les identifiants de staging de ceux de production.
Le schéma typique à deux étages
Une pratique courante consiste à enchaîner un environnement "staging" sans restriction particulière, déploiement immédiat pour valider rapidement.
Ce qui suit ce premier étage
Suivi d'un environnement "production" protégé par une approbation humaine : le job de production attend, littéralement en pause, qu'un reviewer valide dans l'interface GitHub avant de continuer.
Ce que ce mécanisme apporte
Ce mécanisme donne un vrai point de contrôle humain dans un pipeline par ailleurs entièrement automatisé.
La leçon suivante s'attaque à un besoin différent : transporter des fichiers, comme un résultat de build, d'un job à un autre, avec les artifacts.
Commandes & code
Environments
Un environment GitHub ajoute des règles de protection avant qu'un job ne s'exécute (approbation manuelle, délai, secrets dédiés).
name: Deploy to Production
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
environment:
name: production
url: https://app.example.com # affiché comme lien de déploiement dans l'UI GitHub
steps:
- uses: actions/checkout@v4
- name: Déployer
run: ./scripts/deploy.sh production
env:
DEPLOY_TOKEN: ${{ secrets.PROD_DEPLOY_TOKEN }} # secret scoping à "production" uniquement# Configuration côté GitHub : Settings > Environments > production
# [x] Required reviewers : 2 personnes doivent approuver avant exécution du job
# [x] Wait timer : 10 minutes de délai obligatoire avant le déploiement
# [x] Deployment branches : uniquement depuis "main" (empêche un déploiement depuis une branche perso)# Pipeline typique à deux étapes : staging automatique, production avec approbation
jobs:
deploy-staging:
runs-on: ubuntu-latest
environment: staging # pas de reviewers requis -> déploiement immédiat
steps:
- run: ./scripts/deploy.sh staging
deploy-production:
needs: deploy-staging
runs-on: ubuntu-latest
environment: production # bloqué tant que les reviewers n'approuvent pas
steps:
- run: ./scripts/deploy.sh production# Approuver un déploiement en attente depuis le terminal
gh run list --workflow=deploy.yml
gh run view <run-id>
# L'approbation elle-même se fait dans l'UI GitHub (bouton "Review deployments")
# Historique des déploiements par environnement
gh api repos/:owner/:repo/deploymentsRésumé
- Un
environment:peut exiger des reviewers, un délai d'attente, et restreindre les branches sources. - Les secrets scoping à un environment ne sont accessibles QUE par les jobs déclarant cet environment.
- Un pipeline staging -> production typique enchaîne un environment libre puis un environment protégé.
- L'onglet "Environments" du repo garde un historique complet des déploiements et de leur statut.
Exercices pratiques
Mission : un job qui ne trouve plus son secret de production
Objectif : Diagnostiquer une erreur d'accès à un secret d'environment, puis mettre en place le contrôle d'approbation attendu.
Contexte
Le secret PROD_DEPLOY_TOKEN est bien configuré dans l'environment « production » côté GitHub (Settings > Environments). Pourtant, le job deploy-production échoue systématiquement, la variable d'environnement DEPLOY_TOKEN étant vide au moment de l'exécution du script de déploiement. L'équipe veut aussi profiter de l'occasion pour exiger 2 reviewers et restreindre les déploiements à la branche main.