Prérequis et vue d'ensemble

Pourquoi ce module existe

Ce parcours n'a pas de formateur en direct, et « environment » est un mot qui désigne deux choses différentes selon le contexte. Avant de manipuler quoi que ce soit, il faut lever cette ambiguïté — sinon les modules 2 et 5 se contredisent en apparence alors qu'ils parlent de deux niveaux différents.

Les deux sens d'« environment »

1. La fonctionnalité native GitHub Actions (majuscule dans ce parcours pour la distinguer : Environment) — un objet que vous créez dans les paramètres d'un repo (Settings > Environments), avec ses propres secrets, variables et règles de protection. C'est un objet technique concret, avec une interface, une API, et des contraintes de plan précises (module 4).

2. Le concept général d'environnement de déploiement — dev, staging, production, parfois un environnement éphémère par pull request. C'est une notion de stratégie logicielle, indépendante de GitHub : elle existe même sans utiliser la fonctionnalité Environment de GitHub, par exemple si vous déployez via une plateforme tierce qui gère ses propres environnements (module 5).

Les modules 2, 3 et 4 portent sur le sens 1. Le module 5 élargit au sens 2. Le module 6 vous aide à décider comment les deux se combinent (ou non) dans votre cas.

Prérequis

• Un compte GitHub et un repo sur lequel vous avez les droits d'administration (nécessaires pour créer des Environments et modifier les règles de protection).
• Un repo public plutôt que privé pour suivre les manipulations pratiques. GitHub Free ne propose la fonctionnalité Environment (secrets scopés, règles de protection) que sur les repos publics — le module 4 explique cette contrainte de plan en détail. Si votre seul repo disponible est privé et que vous êtes sur un plan Free, créez un repo de test public jetable pour ce parcours.
• Des notions de base de GitHub Actions : savoir qu'un workflow est un fichier YAML dans .github/workflows/, déclenché par un événement (on:), qui exécute des jobs. Ce parcours ne réexplique pas cette base.
• Un éditeur de texte et git pour créer/modifier le fichier de workflow.

Ce que vous saurez faire à la fin

• Distinguer la fonctionnalité Environment de GitHub Actions du concept général d'environnement de déploiement.
• Créer un Environment, y attacher des variables scopées (et savoir comment y ajouter des secrets), et le référencer dans un workflow.
• Configurer des règles de protection (reviewers requis et restriction de branches) et observer leur effet réel sur une exécution ; connaître aussi le délai d'attente et la restriction par tag.
• Expliquer les avantages, les inconvénients et les contraintes de coût/plan de cette fonctionnalité.
• Situer les Environments GitHub par rapport à une stratégie d'environnements plus large (dev/staging/prod, environnements éphémères).
• Choisir, à l'aide d'une matrice de décision, l'approche adaptée à un contexte donné plutôt que par défaut ou par habitude.

Si quelque chose échoue

Si vous n'avez pas les droits admin sur le repo que vous comptiez utiliser, créez un repo public personnel dédié à ce parcours — les manipulations des modules 2 et 3 ne demandent qu'un fichier de workflow minimal et ne modifient rien d'important ; le module 6 ne demande même pas ça, uniquement un repo sur lequel raisonner.