Deploying with GitHub Actions

Introduction

GitHub Actions offers features that let you control deployments. You can:

• Trigger workflows with a variety of events.
• Configure environments to set rules before a job can proceed and to limit access to secrets.
• Use concurrency to control the number of deployments running at a time.

For more information about continuous deployment, see About continuous deployment with GitHub Actions.

Prerequisites

You should be familiar with the syntax for GitHub Actions. For more information, see Écriture de workflows.

Triggering your deployment

You can use a variety of events to trigger your deployment workflow. Some of the most common are: pull_request, push, and workflow_dispatch.

For example, a workflow with the following triggers runs whenever:

• There is a push to the main branch.
• A pull request targeting the main branch is opened, synchronized, or reopened.
• Someone manually triggers it.

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  workflow_dispatch:

For more information, see Événements qui déclenchent des flux de travail.

Using environments

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.

Using concurrency

Concurrency ensures that only a single job or workflow using the same concurrency group will run at a time. You can use concurrency so that an environment has a maximum of one deployment in progress and one deployment pending at a time. For more information about concurrency, see Contrôler la simultanéité des workflows et des tâches.

For example, when the following workflow runs, it will be paused with the status pending if any job or workflow that uses the production concurrency group is in progress. It will also cancel any job or workflow that uses the production concurrency group and has the status pending. This means that there will be a maximum of one running and one pending job or workflow in that uses the production concurrency group.

name: Deployment

concurrency: production

on:
  push:
    branches:
      - main

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

You can also specify concurrency at the job level. This will allow other jobs in the workflow to proceed even if the concurrent job is pending.

name: Deployment

on:
  push:
    branches:
      - main

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

You can also use cancel-in-progress to cancel any currently running job or workflow in the same concurrency group.

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

For guidance on writing deployment-specific steps, see Finding deployment examples.

Viewing deployment history

When a GitHub Actions workflow deploys to an environment, the environment is displayed on the main page of the repository. For more information about viewing deployments to environments, see Consultation de l’historique de déploiement.

Monitoring workflow runs

Every workflow run generates a real-time graph that illustrates the run progress. You can use this graph to monitor and debug deployments. For more information see, Utilisation du graphe de visualisation.

You can also view the logs of each workflow run and the history of workflow runs. For more information, see Affichage de l’historique des exécutions de workflows.

Tracking deployments through apps

If your personal account or organization on GitHub is integrated with Microsoft Teams or Slack, you can track deployments that use environments through Microsoft Teams or Slack. For example, you can receive notifications through the app when a deployment is pending approval, when a deployment is approved, or when the deployment status changes. For more information about integrating Microsoft Teams or Slack, see Intégrations GitHub mises en avant.

You can also build an app that uses deployment and deployment status webhooks to track deployments. 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. For more information, see Documentation sur les applications GitHub and Événements et charges utiles du webhook.

Choosing a runner

You can run your deployment workflow on GitHub-hosted runners or on self-hosted runners. Traffic from GitHub-hosted runners can come from a wide range of network addresses. If you are deploying to an internal environment and your company restricts external traffic into private networks, GitHub Actions workflows running on GitHub-hosted runners may not be able to communicate with your internal services or resources. To overcome this, you can host your own runners. For more information, see About self-hosted runners and Utilisation des exécuteurs hébergés par GitHub.

Displaying a status badge

You can use a status badge to display the status of your deployment workflow. 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.

For more information, see Adding a workflow status badge.

Finding deployment examples

This article demonstrated features of GitHub Actions that you can add to your deployment workflows.

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.