Implantando com GitHub Actions

Pré-requisitos

Você deve estar familiarizado com a sintaxe de GitHub Actions. Para saber mais, confira Escrevendo fluxos de trabalho.

Acionando a sua implantação

Você pode usar uma série de eventos para acionar seu fluxo de trabalho de implantação. Algumas das opções mais comuns são: pull_request, push e workflow_dispatch.

Por exemplo, um fluxo de trabalho com os seguintes gatilhos é executado sempre que:

• Há um push para o branch main.
• Uma solicitação de pull direcionada ao branch main é aberta, sincronizada ou reaberta.
• Alguém a aciona manualmente.

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

Para saber mais, confira Eventos que disparam fluxos de trabalho.

Usar ambientes

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.

Você pode configurar ambientes com regras de proteção e segredos. Quando um trabalho de fluxo de trabalho faz referência a um ambiente, o trabalho não será iniciado até que todas as regras de proteção do ambiente sejam aprovadas. Um trabalho também não pode acessar segredos definidos em um ambiente até que todas as regras de proteção da implantação tenham êxito. Para saber mais, consulte Usando regras de proteção de implantação personalizadas neste artigo.

Usando simultaneidade

A moeda garante que apenas um único trabalho ou fluxo de trabalho que usa o mesmo grupo de concorrência seja executado de cada vez. Você pode usar a concorrência para que um ambiente tenha, no máximo, uma implantação em andamento e uma implantação pendente por vez. Para obter mais informações sobre a simultaneidade, confira Controlar a simultaneidade de fluxos de trabalho e trabalhos.

Por exemplo, quando o fluxo de trabalho a seguir for executado, ele será colocado em pausa com o status pending se qualquer trabalho ou fluxo de trabalho que usa o grupo de simultaneidade production estiver em andamento. Ele também cancelará qualquer trabalho ou fluxo de trabalho que use o grupo de simultaneidade production e que tenha o status pending. Isso significa que haverá, no máximo, um trabalho ou um fluxo de trabalho em execução e um pendente que usa o grupo de simultaneidade production.

name: Deployment

concurrency: production

on:
  push:
    branches:
      - main

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

Você também pode especificar simultaneidade no nível do trabalho. Isso permitirá que outros trabalhos no fluxo de trabalho continuem mesmo que o trabalho simultâneo esteja pending.

name: Deployment

on:
  push:
    branches:
      - main

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

Use também cancel-in-progress para cancelar qualquer trabalho ou fluxo de trabalho em execução no mesmo grupo de simultaneidade.

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

Para obter diretrizes sobre como escrever etapas específicas à implantação, confira Como encontrar exemplos de implantação.

Exibir o histórico de implantações

Quando um fluxo de trabalho de GitHub Actions é implantado em um ambiente, o ambiente é exibido na página principal do repositório. Para saber mais sobre como exibir implantações em ambientes, confira Exibir o histórico de implantações.

Monitoramento de fluxo de trabalho

Cada execução de fluxo de trabalho gera um gráfico em tempo real que ilustra o progresso da execução. Você pode usar este gráfico para monitorar e depurar implantações. Para saber mais, confira Usar o gráfico de visualização.

Você também pode visualizar os registros de cada execução do fluxo de trabalho e o histórico de execuções do fluxo de trabalho. Para saber mais, confira Visualizar o histórico de execução do fluxo de trabalho.

Usando revisões necessárias nos fluxos de trabalho

Os trabalhos que fazem referência a um ambiente configurado com os revisores necessários irão aguardar a aprovação antes de serem iniciados. Enquanto um trabalho está aguardando aprovação, ele tem um status de "Aguardando". Se um trabalho não for aprovado em até 30 dias, falhará automaticamente.

Para obter mais informações sobre ambientes e aprovações necessárias, confira Gerenciar ambientes para implantação. Para obter informações de como examinar implantações com a API REST, confira Pontos de extremidade da API REST para execuções de fluxo de trabalho.

Usando regras de proteção de implantação personalizadas

Você pode habilitar suas próprias regras de proteção personalizadas para bloquear implantações com serviços de terceiros. Por exemplo, você pode usar serviços como Datadog, Honeycomb e ServiceNow para fornecer aprovações automatizadas para implantações no GitHub.

As regras de proteção de implantação personalizadas são alimentadas pelo GitHub Apps e executadas com base em webhooks e retornos de chamada. A aprovação ou rejeição de um trabalho de fluxo de trabalho baseia-se no consumo do webhook deployment_protection_rule. Para saber mais, confira Eventos e cargas de webhook e Aprovação ou rejeição de implantações.

Depois de criar uma regra de proteção de implementação personalizada e instalá-la em seu repositório, a regra de proteção de implementação personalizada estará automaticamente disponível para todos os ambientes no repositório.

As implantações em um ambiente podem ser aprovadas ou rejeitadas com base nas condições definidas em qualquer serviço externo, como um tíquete aprovado em um sistema ITSM (gerenciamento de serviços de TI), resultado de verificação vulnerável em dependências ou métricas de integridade estáveis de um recurso de nuvem. A decisão de aprovar ou rejeitar implantações fica a critério do aplicativo integrador de terceiros e das condições de gating que você define neles. Confira a seguir alguns casos de uso para os quais você pode criar uma regra de proteção de implantação.

• ITSM & Operações de Segurança: você pode verificar a prontidão do serviço validando processos de qualidade, segurança e conformidade que verificam a prontidão da implantação.
• Sistemas de observabilidade: você pode consultar sistemas de monitoramento ou observabilidade (Sistemas de gerenciamento de desempenho de ativos e agregadores de registro, sistemas de verificação de integridade de recursos em nuvem, etc.) para verificar a prontidão de segurança e implantação.
• Ferramentas de teste e qualidade de código: você pode verificar testes automatizados em compilações de CI que precisam ser implantados em um ambiente.

Como alternativa, você pode escrever suas próprias regras de proteção para qualquer um dos casos de uso acima ou pode definir qualquer lógica personalizada para aprovar ou rejeitar implantações com segurança desde a pré-produção até os ambientes de produção.

Rastreando implantações por meio de aplicativos

Você também pode criar um aplicativo que usa webhooks de status de implantação e implantação para rastrear implantações. 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. Para saber mais, confira Documentação de Aplicativos do GitHub e Eventos e cargas de webhook.

Escolher um executor

Você pode executar seu fluxo de trabalho de implantação em executores hospedados no GitHub ou em executores auto-hospedados. O tráfego dos executores hospedados no GitHub pode vir de uma ampla variedade de endereços de rede. Se você está fazendo a implantação em um ambiente interno e a empresa restringe o tráfego externo em redes privadas, os fluxos de trabalho do GitHub Actions em execução nos executores hospedados no GitHub podem não conseguir se comunicar com os serviços ou recursos internos. Para superar isso, você pode hospedar seus próprios executores. Para saber mais, confira Executores auto-hospedados e Executores hospedados no GitHub.

Exibindo um selo de status

Você pode usar um selo de status para exibir o status do seu fluxo de trabalho de implantação. 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.

Para saber mais, confira Adicionar um selo de status de fluxo de trabalho.

Procurando exemplos de implantação

Este artigo mostrou as funcionalidades de GitHub Actions que você pode adicionar aos seus fluxos de trabalho de implantação.

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.