Déploiement 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 pull request ciblant 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 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.

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 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 dans cet article.

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, consultez « 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 flux de travail de continuer à s’exécuter, même si le travail concurrent est 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 ».

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

Utilisation des révisions requises dans les flux de travail

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

Pour plus d’informations sur les environnements et les approbations nécessaires, consultez « Gestion des environnements pour le déploiement ». 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 ».

Utilisation des règles de protection de déploiement personnalisées

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

Les règles de protection de déploiement personnalisées sont alimentées par GitHub Apps et s’exécutent en fonction 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 » et « Approbation ou rejet de déploiements ».

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

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

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

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

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 des 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 runners hébergés par GitHub ou sur des runners 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 « Exécuteurs auto-hébergés » et « 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 « Ajout d’un badge d’état de flux de travail ».

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.

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