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 Escrevendo fluxos de trabalho.

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 Eventos que disparam fluxos de trabalho.

Using environments

Os ambientes são usados para descrever um destino de implantação geral, como production, staging ou development. Quando um fluxo de trabalho de GitHub Actions é implantado em um ambiente, o ambiente é exibido na página principal do repositório. Você pode usar ambientes para exigir aprovação para um trabalho prosseguir, restringir quais ramificações podem acionar um fluxo de trabalho, bloquear implantações com regras de proteção de implantação personalizadas ou limitar o acesso a segredos. Para saber mais sobre como criar ambientes, confira Gerenciar ambientes para implantação.

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 Controlar a simultaneidade de fluxos de trabalho e trabalhos.

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 Exibir o histórico de implantações.

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, Usar o gráfico de visualização.

You can also view the logs of each workflow run and the history of workflow runs. For more information, see Visualizar o histórico de execução do fluxo de trabalho.

Tracking deployments through apps

You can also build an app that uses deployment and deployment status webhooks to track deployments. Quando um trabalho de fluxo de trabalho que referencia um ambiente é executado, ele cria um objeto de implantação com a propriedade environment definida como o nome do ambiente. À medida que o fluxo de trabalho progride, ele também cria objetos de status de implantação com a propriedade environment definida como o nome do ambiente, a propriedade environment_url definida como a URL para o ambiente (se especificado no fluxo de trabalho) e a propriedade state definida como o status do trabalho. For more information, see Documentação de Aplicativos do GitHub and Eventos e cargas de 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 Usar executores hospedados no GitHub.

Displaying a status badge

You can use a status badge to display the status of your deployment workflow. Um selo de status mostra se um fluxo de trabalho está falhando ou passando. Um local comum para adicionar uma notificação de status é no arquivo README.md do repositório, mas você pode adicioná-lo a qualquer página da Web desejada. Por padrão, os selos exibem o status do seu branch-padrão. Se não houver execuções de fluxo de trabalho em seu branch padrão, ele exibirá o status da execução mais recente em todos os branches. Você pode exibir o status de uma execução de fluxo de trabalho para um branch ou um evento específico usando os parâmetros de consulta branch e event na URL.

For more information, see Adicionar um selo de status de fluxo de trabalho.

Finding deployment examples

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

O GitHub oferece modelos de fluxo de trabalho de implantação para vários serviços populares, como o aplicativo Web Azure. Para saber como começar a usar um modelo de fluxo de trabalho, confira Usando modelos de fluxo de trabalho ou navegue pela lista completa de modelos de fluxo de trabalho de implantação. Confira também nossos guias mais detalhados de fluxos de trabalho de implantação específicos, como Implantando o Node.js no Azure App Service.

Muitos prestadores de serviço também oferecem ações em GitHub Marketplace para implantar no seu serviço. Para ver a lista completa, confira GitHub Marketplace.