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.
GitHub AE est actuellement en version limitée.

Déploiement avec GitHub Actions

Apprenez à contrôler les déploiements à l’aide de fonctionnalités comme les environnements et la concurrence.

Introduction

GitHub Actions offre des fonctionnalités qui vous permettent de contrôler les déploiements. Vous pouvez :

  • Déclencher des workflows avec une grande variété d’événements.
  • Configurer des environnements pour définir des règles sur la poursuite d’un travail et pour limiter l’accès aux secrets.
  • Utiliser la concurrence pour contrôler le nombre de déploiements qui peuvent s’exécuter simultanément.

Pour plus d’informations sur le déploiement continu, consultez « À propos du déploiement continu ».

Prérequis

Vous devez être familiarisé avec la syntaxe GitHub Actions. Pour plus d’informations, consultez « Découvrir GitHub Actions ».

Déclenchement de votre déploiement

Vous pouvez utiliser divers événements pour déclencher votre workflow de déploiement. Les plus courants sont pull_request, push et workflow_dispatch.

Par exemple, un workflow avec les déclencheurs suivants s’exécute quand :

  • Un élément est poussé (push) vers la branche main.
  • Une demande de tirage (pull request) ciblant la branche main est ouverte, synchronisée ou rouverte.
  • Quelqu’un le déclenche manuellement.
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  workflow_dispatch:

Pour plus d’informations sur les événements, consultez « Événements qui déclenchent des workflows ».

Utilisation 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. Vous pouvez utiliser des environnements pour exiger l’approbation d’un travail, restreindre les branches pouvant déclencher un workflow ou limiter l’accès aux secrets. Pour plus d’informations sur la création d’environnements, consultez « Utilisation d’environnements pour le déploiement ».

Utilisation de la concurrence

Avec 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 la concurrence pour qu’un environnement ait au maximum un déploiement en cours et un déploiement en attente.

Remarque : 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.

Par 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.

name: Deployment

concurrency: production

on:
  push:
    branches:
      - main

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

Vous pouvez également spécifier la concurrence au niveau du travail. Cela permet aux autres travaux du workflow de continuer à s’exécuter, même si le travail simultané est à l’état pending.

name: Deployment

on:
  push:
    branches:
      - main

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

Vous pouvez également utiliser cancel-in-progress pour annuler tout travail ou workflow en cours d’exécution dans le même groupe de concurrence.

name: Deployment

concurrency: 
  group: production
  cancel-in-progress: true

on:
  push:
    branches:
      - main

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

Pour obtenir des conseils sur l’écriture d’étapes spécifiques au déploiement, consultez « Trouver des exemples de déploiement ».

Consultation de l’historique de déploiement

Lorsqu’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 « Affichage de l’historique des déploiements ».

Monitoring des exécutions de workflows

Chaque 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 ».

Vous 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 ».

Suivi des déploiements via des applications

Vous 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. 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. Pour plus d’informations, consultez « Applications » et « Événements et charges utiles de webhook  ».

Affichage d’un badge d’état

Vous 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. Vous pouvez également 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.

exemple de badge d’état

Pour plus d’informations, consultez « Ajout d’un badge d’état de workflow ».

Trouver des exemples de déploiements

Cet article a montré les fonctionnalités de GitHub Actions que vous pouvez ajouter à vos workflows de déploiement.

GitHub AE propose des workflows de démarrage de déploiement pour plusieurs services populaires, comme Azure Web App. Pour plus d’informations sur l’utilisation d’un workflow de démarrage, consultez « Utilisation des workflows de démarrage » ou parcourez la liste complète des workflows de démarrage de déploiement. Vous pouvez également consulter nos guides détaillés consacrés à des workflows de déploiement spécifiques, tels que « Déploiement sur Azure App Service ».

De nombreux fournisseurs de services proposent également des actions sur GitHub Marketplace pour un déploiement dans leur service. Pour obtenir la liste complète, consultez GitHub Marketplace.