Déploiement avec GitHub Actions

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 avec GitHub Actions ».

Prérequis

Vous devez être familiarisé avec la syntaxe GitHub Actions. Pour plus d’informations, consultez « Écriture de workflows ».

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, consultez « Événements qui déclenchent des flux de travail ».

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, contrôler les déploiements avec des règles de protection de déploiement personnalisées, 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 ».

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. Pour en savoir plus sur la concurrence, reportez-vous à « Contrôler la simultanéité des workflows et des tâches. »

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 « Consultation de l’historique de déploiement ».

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 « Documentation sur les applications GitHub » et « Événements et charges utiles du webhook ».

Choix de l’exécuteur

Vous pouvez exécuter votre workflow de déploiement sur des exécuteurs hébergés dans GitHub ou sur des exécuteurs auto-hébergés. Le trafic provenant des exécuteurs hébergés dans GitHub peut provenir d’une large plage d’adresses réseau. Si vous effectuez un déploiement dans un environnement interne et si votre entreprise restreint le trafic externe vers les réseaux privés, les workflows GitHub Actions s’exécutant sur des exécuteurs hébergés dans GitHub pourront 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 « À propos des exécuteurs auto-hébergés » et « Utilisation des exécuteurs hébergés par GitHub ».

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

Pour plus d’informations, consultez « Adding a workflow status badge ».

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 Enterprise Server propose des modèles de workflow 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 » ou consultez la liste complète des modèles de workflow 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 de Node.js 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.