{"meta":{"title":"Déploiement avec GitHub Actions","intro":"GitHub Actions vous offre un contrôle précis sur les déploiements grâce à des environnements, des groupes de concurrence, et des règles de sécurité.","product":"GitHub Actions","breadcrumbs":[{"href":"/fr/actions","title":"GitHub Actions"},{"href":"/fr/actions/how-tos","title":"Guides pratiques"},{"href":"/fr/actions/how-tos/deploy","title":"Déployer"},{"href":"/fr/actions/how-tos/deploy/configure-and-manage-deployments","title":"Configurer et gérer les déploiements"},{"href":"/fr/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments","title":"Contrôler les déploiements"}],"documentType":"article"},"body":"# Déploiement avec GitHub Actions\n\nGitHub Actions vous offre un contrôle précis sur les déploiements grâce à des environnements, des groupes de concurrence, et des règles de sécurité.\n\n## Prérequis\n\nVous devez être familiarisé avec la syntaxe pour GitHub Actions. Pour plus d’informations, consultez « [Écriture de workflows](/fr/actions/how-tos/write-workflows) ».\n\n## Déclenchement de votre déploiement\n\nVous pouvez utiliser divers événements pour déclencher votre workflow de déploiement. Les plus courants sont `pull_request`, `push` et `workflow_dispatch`.\n\nPar exemple, un workflow avec les déclencheurs suivants s’exécute quand :\n\n* Un élément est poussé (push) vers la branche `main`.\n* Une demande de pull request ciblant branche `main` est ouverte, synchronisée ou rouverte.\n* Quelqu’un le déclenche manuellement.\n\n```yaml\non:\n  push:\n    branches:\n      - main\n  pull_request:\n    branches:\n      - main\n  workflow_dispatch:\n```\n\nPour plus d’informations, consultez « [Événements qui déclenchent des flux de travail](/fr/actions/reference/workflows-and-actions/events-that-trigger-workflows) ».\n\n## Utilisation des environnements\n\nLes environnements sont utilisés pour décrire une cible de déploiement général comme `production`, `staging` ou `development`. Lorsqu’un GitHub Actions flux de travail est déployé dans un environnement, l’environnement s’affiche sur la page principale du référentiel. Vous pouvez utiliser les environnements pour exiger l’approbation d’un travail, restreindre les branches pouvant déclencher un flux de travail, contrôler les déploiements avec des règles personnalisées de protection des déploiements ou limiter l’accès aux secrets. Pour plus d’informations sur la création d’environnements, consultez [Gestion des environnements pour le déploiement](/fr/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments).\n\nVous 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 projet ne peut pas non plus accéder à des secrets définis dans un environnement tant que toutes les règles de protection du déploiement n’ont pas été validées. Pour en savoir plus, consultez [Utilisation des règles de protection de déploiement personnalisées](#using-custom-deployment-protection-rules) dans cet article.\n\n## Utilisation de la concurrence\n\nAvec la concurrence, vous ne pouvez exécuter qu’un seul travail ou workflow d’un même groupe de concurrence à la fois. Vous pouvez utiliser l’accès concurrentiel afin qu’un environnement dispose d’un maximum d’un déploiement en cours à la fois. Pour en savoir plus sur la concurrence, consultez « [Contrôler la simultanéité des workflows et des tâches](/fr/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency) ».\n\n## Utilisation d’environnements sans déploiements\n\nPar défaut, lorsqu’un travail de workflow fait référence à un environnement, GitHub crée un objet de déploiement pour suivre le déploiement. Vous pouvez choisir de ne pas créer de déploiement en définissant`deployment`sur`false`dans la configuration de l’environnement. Les valeurs valides sont `true` (par défaut) et `false`. Vous pouvez également utiliser une expression, par exemple `deployment: ${{ github.ref_name == 'main' }}`.\n\n```yaml\njobs:\n  test:\n    runs-on: ubuntu-latest\n    environment:\n      name: staging\n      deployment: false\n    steps:\n      - name: run tests\n        env:\n          API_KEY: ${{ secrets.API_KEY }}\n        run: echo \"Running tests with staging secrets\"\n```\n\nQuand `deployment` est défini sur `false`:\n\n* La tâche a un accès complet aux secrets et aux variables de l'environnement.\n* Aucun objet de déploiement n’est GitHub créé : l’historique de déploiement de l’environnement n’est pas mis à jour.\n* Les règles de protection du minuteur d’attente s’appliquent toujours : le job attend la durée configurée.\n* Les réviseurs requis sont toujours nécessaires : les réviseurs doivent encore approuver avant l’exécution de la tâche.\n\nCela est utile lorsque vous souhaitez utiliser des environnements pour :\n\n* **Organisation des secrets** : regrouper les secrets associés sous un nom d’environnement sans créer d’enregistrements de déploiement.\n* **Contrôle d’accès** : restreindre les branches qui peuvent utiliser certains secrets via des stratégies de branche d’environnement, sans suivi du déploiement.\n* **CI et travaux de test** : référencez un environnement pour sa configuration sans ajouter de bruit à l’historique du déploiement.\n\n### Interaction avec les règles de protection\n\nLa propriété `deployment` détermine quelles règles de protection s’appliquent :\n\n\\| Règle de protection |\n`deployment: true` (valeur par défaut) | `deployment: false` |\n\\|----------------|------------------------------|---------------------|\n\\| **Aucun** | Déploiement créé, le job s’exécute | Pas de déploiement, le job s’exécute |\n\\| **Minuteur d’attente** | Minuteur d'attente enforcé | Minuteur d’attente toujours appliqué |\n\\| **Réviseurs requis** | Les réviseurs doivent approuver | Les réviseurs doivent approuver |\n\\| **Application de règle de protection de déploiement personnalisée** | Le webhook d'application envoyé doit être approuvé |\n**Le travail échoue avec une erreur** |\n\nLes règles de protection de déploiement personnalisées (GitHub Apps) nécessitent un objet de déploiement pour fonctionner. Si vous définissez `deployment: false` sur un environnement qui a des règles de protection de déploiement personnalisées, le travail échoue immédiatement avec une annotation ou un message d’erreur expliquant que les règles de protection de l’environnement sont incompatibles avec `deployment: false`. Supprimez `deployment: false` de votre flux de travail, ou supprimez les règles de protection de déploiement personnalisées de l'environnement.\n\nNotez que `concurrency` et `environment` ne sont pas connectés. Vous pouvez utiliser n’importe quelle chaîne comme valeur de concurrence. Il n’est pas nécessaire que ce soit un nom d’environnement. En outre, si un autre workflow utilise le même environnement mais ne spécifie pas la concurrence, ce workflow ne sera soumis à aucune règle de concurrence.\n\nPar exemple, lorsque le workflow suivant s’exécute, il est suspendu avec l’état `pending` si un travail ou un workflow qui utilise le groupe de concurrence `production` est en cours d’exécution. Cela annulera également tout travail ou workflow qui utilise le groupe de concurrence `production` et qui a l’état `pending`. Cela signifie qu’il y aura au maximum un travail ou workflow en cours d’exécution, et un autre en attente qui utilisent le groupe de concurrence `production`.\n\n```yaml\nname: Deployment\n\nconcurrency: production\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nVous pouvez également spécifier la concurrence au niveau du travail. Cela permet aux autres travaux du flux de travail de continuer à s’exécuter, même si le travail concurrent est `pending`.\n\n```yaml\nname: Deployment\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    concurrency: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nVous pouvez également utiliser `cancel-in-progress` pour annuler tout travail ou workflow en cours d’exécution dans le même groupe de concurrence.\n\n```yaml\nname: Deployment\n\nconcurrency:\n  group: production\n  cancel-in-progress: true\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nPour obtenir des conseils sur l’écriture d’étapes spécifiques au déploiement, consultez « [Trouver des exemples de déploiement](#finding-deployment-examples) ».\n\n## Consultation de l’historique de déploiement\n\nLorsqu’un GitHub Actions flux de travail est déployé dans un environnement, l’environnement s’affiche sur la page principale du référentiel. Pour plus d’informations sur l’affichage des déploiements dans les environnements, consultez « [Consultation de l’historique de déploiement](/fr/actions/how-tos/deploy/configure-and-manage-deployments/view-deployment-history) ».\n\nVotre organisation peut rassembler des enregistrements de déploiement pour l'ensemble de vos builds dans un emplacement centralisé en chargeant les données dans le linked artifacts page. Consultez « [À propos des artefacts liés](/fr/code-security/concepts/supply-chain-security/linked-artifacts) ».\n\n## Surveillance des exécutions de workflows\n\nChaque exécution de workflow génère un graphe en temps réel qui illustre la progression de l’exécution. Vous pouvez utiliser ce graphe pour monitorer et déboguer les déploiements. Pour plus d’informations, consultez [Utilisation du graphe de visualisation](/fr/actions/how-tos/monitor-workflows/use-the-visualization-graph).\n\nVous pouvez également afficher les journaux d’activité de chaque exécution de workflow, ainsi que l’historique des exécutions de workflows. Pour plus d’informations, consultez « [Affichage de l’historique des exécutions de workflows](/fr/actions/how-tos/monitor-workflows/view-workflow-run-history) ».\n\n## Utilisation des révisions requises dans les flux de travail\n\nLes travaux qui font référence à un environnement configuré avec les réviseurs requis attendent une approbation avant de démarrer. Lorsqu’un travail est en attente d’approbation, il est à l’état « En attente ». Si un travail n’est pas approuvé dans les 30 jours, il échouera automatiquement.\n\nPour plus d’informations sur les environnements et les approbations nécessaires, consultez « [Gestion des environnements pour le déploiement](/fr/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments) ». Pour plus d’informations sur la façon de passer en revue les déploiements avec l’API REST, consultez « [Points de terminaison d'API REST pour l'exécution des workflows](/fr/rest/actions/workflow-runs) ».\n\n## Utilisation des règles de protection de déploiement personnalisées\n\n> \\[!NOTE]\n> Les règles de protection de déploiement personnalisées sont actuellement en préversion publique et sont susceptibles d’être modifiées.\n\nVous pouvez activer vos propres règles de protection personnalisées pour contrôler les déploiements avec des services tiers. Par exemple, vous pouvez utiliser des services comme Datadog, Honeycomb et ServiceNow pour fournir des approbations automatisées pour les déploiements sur GitHub.\n\nLes règles personnalisées de protection du déploiement reposent sur GitHub Apps et s’exécutent selon des webhooks et des rappels. L’approbation ou le rejet d’un travail de workflow est basé sur la consommation du webhook `deployment_protection_rule`. Pour plus d’informations, consultez « [Événements et charges utiles du webhook](/fr/webhooks/webhook-events-and-payloads#deployment_protection_rule) » et « [Approbation ou rejet de déploiements](/fr/actions/how-tos/deploy/configure-and-manage-deployments/create-custom-protection-rules#approving-or-rejecting-deployments) ».\n\nUne fois que vous avez créé une règle de protection de déploiement personnalisée et que vous l’avez installée sur votre dépôt, la règle de protection de déploiement personnalisée est automatiquement disponible pour tous les environnements du dépôt.\n\nLes déploiements dans un environnement peuvent être approuvés ou rejetés en fonction des conditions définies dans n’importe quel service externe, comme un ticket approuvé dans un système ITSM (gestion des services informatiques), un résultat d’analyse des vulnérabilités sur les dépendances ou des métriques d’intégrité stables d’une ressource cloud. La décision d’approuver ou de rejeter les déploiements est à la discrétion de l’application tierce qui l'intègre et des conditions de passage que vous définissez dans cette application. Voici quelques cas d’usage pour lesquels vous pouvez créer une règle de protection de déploiement.\n\n* Opérations de sécurité et ITSM : vous pouvez vérifier la préparation du service en validant les processus de qualité, de sécurité et de conformité qui s’assurent de la préparation au déploiement.\n* Systèmes d’observabilité : vous pouvez consulter les systèmes de supervision ou d’observabilité (systèmes de gestion des performances des ressources et agrégateurs de journalisation, systèmes de vérification de l’intégrité des ressources cloud, etc.) pour vérifier la sécurité et la préparation au déploiement.\n* Outils de qualité du code et de test : vous pouvez vérifier les tests automatisés sur les builds CI qui doivent être déployées dans un environnement.\n\nVous pouvez également écrire vos propres règles de protection pour l’un des cas d’usage ci-dessus ou définir une logique personnalisée pour approuver ou rejeter en toute sécurité les déploiements de préproduction dans les environnements de production.\n\n## Suivi des déploiements via des applications\n\nSi votre compte personnel ou votre organisation sur GitHub est intégré à Microsoft Teams ou Slack, vous pouvez suivre les déploiements qui utilisent des environnements via Microsoft Teams ou Slack. Par exemple, vous pouvez recevoir des notifications via l’application lorsqu’un déploiement est en attente d’approbation, lorsqu’un déploiement est approuvé ou lorsque l’état du déploiement change. Pour plus d’informations sur l’intégration Microsoft Teams ou Slack, consultez [Intégrations GitHub proposées](/fr/integrations/concepts/featured-github-integrations#team-communication-tools).\n\nVous pouvez également créer une application qui utilise des webhooks de déploiement et d’état de déploiement pour effectuer le suivi des déploiements.\nQuand 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. Pour plus d’informations, consultez [Documentation des applications GitHub](/fr/apps) et [Événements et charges utiles du webhook](/fr/webhooks/webhook-events-and-payloads#deployment).\n\n## Choix de l’exécuteur\n\nVous pouvez exécuter votre workflow de déploiement sur des exécuteurs hébergés par GitHub ou sur des exécuteurs auto-hébergés. Le trafic provenant des GitHubexécuteurs hébergés peut provenir [d’un large éventail d’adresses réseau](/fr/rest/meta/meta#get-github-meta-information). Si vous déployez dans un environnement interne et que votre entreprise restreint le trafic externe vers les réseaux privés, les workflows GitHub Actions exécutés sur des runners hébergés par GitHub risquent de ne pas pouvoir communiquer avec vos services ou ressources internes. Pour surmonter ce problème, vous pouvez héberger vos propres exécuteurs. Pour plus d’informations, consultez « [Exécuteurs auto-hébergés](/fr/actions/concepts/runners/self-hosted-runners) » et « [Exécuteurs hébergés par GitHub](/fr/actions/concepts/runners/github-hosted-runners) ».\n\n## Affichage d’un badge d’état\n\nVous pouvez utiliser un badge d’état pour afficher l’état de votre workflow de déploiement. Un badge d’état indique si un workflow est en train d’échouer ou de réussir. En règle générale, vous ajoutez un badge d’état dans le fichier `README.md` de votre dépôt, mais vous pouvez l’ajouter dans n’importe quelle page web de votre choix. Par défaut, les badges affichent l’état de votre branche par défaut. Si aucun flux de travail n’est exécuté sur votre branche par défaut, ils affichent l’état de l’exécution la plus récente sur toutes les branches. Vous pouvez afficher l’état d’une exécution de workflow pour une branche ou un événement spécifique en utilisant les paramètres de requête `branch` et `event` dans l’URL.\n\n![Capture d’écran d’un badge d’état de workflow. De droite à gauche, le logo GitHub, le nom du flux de travail (« Version de démonstration GitHub Actions ») et l’état (« Passé ») sont affichés.](/assets/images/help/repository/actions-workflow-status-badge.png)\n\nPour plus d’informations, consultez « [Ajout d’un badge d’état de flux de travail](/fr/actions/how-tos/monitor-workflows/add-a-status-badge) ».\n\n## Trouver des exemples de déploiements\n\nCet article a montré les fonctionnalités de GitHub Actions que vous pouvez ajouter à vos workflows de déploiement.\n\nGitHubpropose des modèles de flux de travail de déploiement pour plusieurs services populaires, tels que Azure Web App. Pour savoir comment commencer à utiliser un modèle de workflow, consultez [Utilisation de modèles de workflow](/fr/actions/how-tos/write-workflows/use-workflow-templates) ou [consultez la liste complète des modèles de workflow de déploiement](https://github.com/actions/starter-workflows/tree/main/deployments). Vous pouvez également consulter nos guides détaillés consacrés à des workflows de déploiement spécifiques, tels que [Déploiement de Node.js sur Azure App Service](/fr/actions/how-tos/deploy/deploy-to-third-party-platforms/nodejs-to-azure-app-service).\n\nDe nombreux fournisseurs de services proposent également des actions sur GitHub Marketplace pour déployer sur leur service. Pour obtenir la liste complète, consultez [GitHub Marketplace](https://github.com/marketplace?category=deployment\\&type=actions)."}