Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

Utilisation d’environnements pour le déploiement

Vous pouvez configurer les environnements avec des règles de protection et des secrets. Un travail de workflow qui fait référence à un environnement doit respecter les règles de protection de l’environnement avant d’exécuter les secrets de l’environnement ou d’y accéder.

Des environnements, des secrets d’environnement et des règles de protection d’environnement sont disponibles dans les dépôts publics pour tous les produits. Pour accéder aux environnements, secrets d’environnement et branches de déploiement dans des dépôts privés ou internes, vous devez utiliser GitHub Pro, GitHub Team ou GitHub Enterprise. Pour accéder à d’autres règles de protection d’environnement dans des dépôts privés ou internes, vous devez utiliser GitHub Enterprise. Pour plus d’informations, consultez « Produits de GitHub ».

À propos des environnements

Les environnements sont utilisés pour décrire une cible de déploiement général comme production, staging ou development. Quand un workflow GitHub Actions est déployé dans un environnement, l’environnement s’affiche dans la page principale du dépôt. Pour plus d’informations sur l’affichage des déploiements dans les environnements, consultez « Consultation de l’historique de déploiement ».

Vous pouvez configurer les environnements avec des règles de protection et des secrets. Lorsqu’un travail de workflow référence un environnement, le travail démarre seulement après que toutes les règles de protection de l’environnement sont validées. Un travail ne peut pas non plus accéder à des secrets définis dans un environnement tant que toutes les règles de protection de l’environnement n’ont pas été validées.

Si vous le souhaitez, vous pouvez contourner les règles de protection d’un environnement et forcer tous les travaux en attente référençant l’environnement à continuer. Pour plus d’informations, consultez « Révision des déploiements ».

Remarque : Vous ne pouvez configurer des environnements que pour les dépôts publics. Si vous convertissez un dépôt public en dépôt privé, les règles de protection et les secrets d’environnement configurés sont ignorés et vous ne pourrez pas configurer d’environnements. Si vous convertissez votre dépôt pour le rendre à nouveau public, vous avez accès à toutes les règles de protection et à tous les secrets d’environnement précédemment configurés.

Les organisations avec GitHub Team et les utilisateurs avec GitHub Pro peuvent configurer des environnements pour les référentiels privés. Pour plus d’informations, consultez « Produits de GitHub ».

Règles de protection de l’environnement

Les règles de protection de l’environnement nécessitent la validation de conditions spécifiques pour qu’un travail référençant l’environnement puisse continuer. Vous pouvez utiliser des règles de protection de l’environnement pour exiger une approbation manuelle, retarder un travail ou restreindre l’environnement à certaines branches.

Réviseurs requis

Utilisez des réviseurs requis pour exiger qu’une personne ou équipe spécifique soit chargée d’approuver les travaux de workflow qui référencent l’environnement. Vous pouvez lister jusqu’à six utilisateurs ou équipes comme réviseurs. Les réviseurs doivent avoir au moins un accès en lecture au dépôt. Seul l’un des réviseurs requis doit approuver le travail pour qu’il continue.

Pour plus d’informations sur les travaux de révision qui référencent un environnement avec des réviseurs requis, consultez « Révision des déploiements ».

Minuteur d’attente

Utilisez un minuteur d’attente pour retarder d’un certain temps un travail après son déclenchement. Le temps (en minutes) doit être un entier compris entre 0 et 43 200 (30 jours).

Ne pas laisser les administrateurs contourner les règles de protection

Empêchez les administrateurs de contourner les règles de protection de l’environnement configurées.

Branches de déploiement

Utilisez des branches de déploiement pour restreindre les branches qui peuvent être déployées dans l’environnement. Voici les options des branches de déploiement pour un environnement :

  • Toutes les branches : toutes les branches du dépôt peuvent être déployées dans l’environnement.

  • Branches protégées : seules les branches avec des règles de protection de branche activées peuvent être déployées dans l’environnement. Si aucune règle de protection de branche n’est définie pour une branche dans le dépôt, toutes les branches peuvent être déployées. Pour plus d’informations sur les règles de protection de branche, consultez « À propos des branches protégées ».

  • Branches sélectionnées: seules les branches qui correspondent à vos modèles de nom spécifiés peuvent être déployées dans l’environnement.

    Par exemple, si vous spécifiez releases/* comme règle de branche de déploiement, seules les branches dont le nom commence par releases/ peuvent être déployées dans l’environnement. (Les caractères génériques ne correspondent pas à /. Pour faire correspondre les branches qui commencent par release/ et qui contiennent une barre oblique unique supplémentaire, utilisez release/*/*.) Si vous ajoutez main en tant que règle de branche de déploiement, une branche nommée main peut également être déployée dans l’environnement. Pour plus d’informations sur les options de syntaxe des branches de déploiement, consultez la documentation Ruby sur File.fnmatch.

Secrets d’environnement

Les secrets stockés dans un environnement sont disponibles uniquement pour les travaux de workflow qui référencent l’environnement. Si l’environnement nécessite une approbation, un travail ne peut pas accéder aux secrets d’environnement tant que l’un des réviseurs requis ne l’approuve pas. Pour plus d’informations sur les secrets, consultez « Secrets chiffrés ».

Remarque : Les workflows qui s’exécutent sur des exécuteurs auto-hébergés ne sont pas exécutés dans un conteneur isolé, même s’ils utilisent des environnements. Les secrets d’environnement doivent être traités avec le même niveau de sécurité que les secrets de dépôt et d’organisation. Pour plus d’informations, consultez « Durcissement de la sécurité pour GitHub Actions ».

Variables d'environnement

Les variables stockées dans un environnement sont disponibles uniquement pour les travaux de workflow qui référencent l’environnement. Ces variables sont accessibles uniquement à l’aide du contexte vars. Pour plus d’informations, consultez « Variables ».

Création d’un environnement

Pour configurer un environnement dans un référentiel de comptes personnels, vous devez être le propriétaire du référentiel. Pour configurer un environnement dans un référentiel d’organisation, vous devez disposer d’un accès admin.

Remarque : La création d’un environnement dans un référentiel privé est disponible pour les organisations avec GitHub Team et les utilisateurs avec GitHub Pro.

  1. Dans GitHub.com, accédez à la page principale du dépôt. 1. Sous le nom de votre dépôt, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant et cliquez sur Paramètres.

    Capture d’écran d’un en-tête de dépôt montrant les onglets. L’onglet « Paramètres » est mis en évidence avec un encadré orange foncé. 1. Dans la barre latérale gauche, cliquez sur Environnements. 1. Cliquez sur Nouvel environnement. 1. Entrez un nom pour l’environnement, puis cliquez sur Configurer l’environnement. Les noms d’environnements ne respectent pas la casse. Un nom d’environnement ne peut pas dépasser 255 caractères et doit être unique dans le dépôt.

  2. Si vous le souhaitez, spécifiez des personnes ou des équipes qui doivent approuver les travaux de workflow qui utilisent cet environnement.

    1. Sélectionnez Required reviewers.
    2. Entrez jusqu’à 6 personnes ou équipes. Seul l’un des réviseurs requis doit approuver le travail pour qu’il continue.
    3. Cliquez sur Enregistrer les règles de protection.
  3. Si vous le souhaitez, spécifiez le temps d’attente avant d’autoriser les travaux de workflow qui utilisent cet environnement à poursuivre.

    1. Sélectionnez Minuteur d’attente.
    2. Entrez le nombre de minutes à attendre.
    3. Cliquez sur Enregistrer les règles de protection.
  4. Si vous le souhaitez, empêchez les administrateurs de contourner les règles de protection de l’environnement. Pour plus d’informations sur le contournement des règles de protection de l’environnement, consultez « Révision des déploiements ».

    1. Sélectionnez Ne pas autoriser les administrateurs à contourner les règles de protection.
    2. Cliquez sur Enregistrer les règles de protection.
  5. Si vous le souhaitez, spécifiez les branches qui peuvent être déployées dans cet environnement. Pour plus d’informations sur les valeurs possibles, consultez « Branches de déploiement ».

    1. Sélectionnez l’option souhaitée dans la liste déroulante Branches de déploiement.
    2. Si vous avez choisi Branches sélectionnées, entrez les modèles de nom de branche que vous souhaitez autoriser.
  6. Si vous le souhaitez, ajoutez des secrets d’environnement. Ces secrets sont disponibles uniquement pour les travaux de workflow qui utilisent l’environnement. En outre, les travaux de workflow qui utilisent cet environnement peuvent uniquement accéder à ces secrets après la validation des règles éventuellement configurées (par exemple, les réviseurs requis). Pour plus d’informations sur les secrets, consultez « Secrets chiffrés ».

    1. Sous Secrets d’environnement, cliquez sur Ajouter un secret.
    2. Entrez le nom du secret.
    3. Entrez la valeur du secret.
    4. Cliquez sur Ajouter un secret.
  7. Si vous le souhaitez, ajoutez des variables d’environnement. Ces variables sont uniquement disponibles pour les travaux de workflow qui utilisent l’environnement, et sont uniquement accessibles à l’aide du contexte vars. Pour plus d’informations, consultez « Variables ».

    1. Sous Variables d’environnement, cliquez sur Ajouter une variable.
    2. Entrez le nom de la variable.
    3. Entrez la valeur de la variable.
    4. Cliquez sur Ajouter une variable.

Vous pouvez également créer et configurer des environnements via l’API REST. Pour plus d’informations, consultez « Environnements de déploiement », « Secrets GitHub Actions », « Variables GitHub Actions », et « Stratégies de branche de déploiement ».

L’exécution d’un workflow qui référence un environnement qui n’existe pas crée un environnement avec le nom référencé. L’environnement nouvellement créé n’aura pas de règles de protection ni de secrets configurés. Toute personne qui peut modifier des workflows dans le dépôt peut créer des environnements via un fichier de workflow, mais seuls les administrateurs de dépôt peuvent configurer l’environnement.

Utilisation d’un environnement

Chaque travail d’un workflow peut référencer un seul environnement. Toutes les règles de protection configurées pour l’environnement doivent être validées pour qu’un travail référençant l’environnement soit envoyé à un exécuteur. Le travail peut accéder aux secrets de l’environnement après seulement que le travail a été envoyé à un exécuteur.

Quand un workflow référence un environnement, l’environnement apparaît dans les déploiements du dépôt. Pour plus d’informations sur l’affichage des déploiements actuels et précédents, consultez « Consultation de l’historique de déploiement ».

Vous pouvez spécifier un environnement pour chacun des travaux de votre workflow. Pour ce faire, ajoutez une clé jobs.<job_id>.environment suivie du nom de l’environnement.

Par exemple, ce workflow utilise un environnement appelé production.

name: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: deploy
        # ...deployment-specific steps

Lorsque le workflow ci-dessus s’exécute, le travail deployment est soumis à toutes les règles configurées pour l’environnement production. Par exemple, si l’environnement nécessite des réviseurs, le travail s’interrompt jusqu’à ce que l’un des réviseurs approuve le travail.

Vous pouvez également spécifier une URL pour l’environnement. L’URL spécifiée apparaît sur la page des déploiements du référentiel (accessible en cliquant sur Environnements sur la page d’accueil de votre référentiel) et dans le graphique de visualisation de l’exécution du workflow. Si une demande de tirage (pull request) a déclenché le workflow, l’URL apparaît également sous forme de bouton Afficher le déploiement dans la chronologie de la demande de tirage.

name: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: 
      name: production
      url: https://github.com
    steps:
      - name: deploy
        # ...deployment-specific steps

Suppression d’un environnement

Pour configurer un environnement dans un référentiel de comptes personnels, vous devez être le propriétaire du référentiel. Pour configurer un environnement dans un référentiel d’organisation, vous devez disposer d’un accès admin.

La suppression d’un environnement supprime toutes les règles de protection et tous les secrets associés à l’environnement. Tous les travaux actuellement en attente en raison de règles de protection de l’environnement supprimé échouent automatiquement.

  1. Dans GitHub.com, accédez à la page principale du dépôt. 1. Sous le nom de votre dépôt, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant et cliquez sur Paramètres.

    Capture d’écran d’un en-tête de dépôt montrant les onglets. L’onglet « Paramètres » est mis en évidence avec un encadré orange foncé. 1. Dans la barre latérale gauche, cliquez sur Environnements.

  2. À côté de l’environnement que vous souhaitez supprimer, cliquez sur .

  3. Cliquez sur Je comprends, supprimez cet environnement.

Vous pouvez également supprimer des environnements via l’API REST. Pour plus d’informations, consultez « Référentiels ».

Relation entre les environnements et les déploiements

Quand un travail de workflow qui référence un environnement s’exécute, il crée un objet de déploiement avec la propriété environment définie sur le nom de votre environnement. Au fur et à mesure que le workflow progresse, il crée aussi des objets d’état de déploiement avec la propriété environment définie sur le nom de votre environnement, la propriété environment_url définie sur l’URL de l’environnement (si elle est spécifiée dans le workflow) et la propriété state définie sur l’état du travail.

Vous pouvez accéder à ces objets via l’API REST ou l’API GraphQL. Vous pouvez également vous abonner à ces événements webhook. Pour plus d’informations, consultez « Référentiels » (API REST), « Objets » (API GraphQL) ou « Événements et charges utiles du webhook ».

Étapes suivantes

GitHub Actions fournit plusieurs fonctionnalités pour la gestion de vos déploiements. Pour plus d’informations, consultez « Déploiement avec GitHub Actions ».