Note
No momento, não há suporte para executores hospedados no GitHub no GitHub Enterprise Server. Você pode ver mais informações sobre o suporte futuro planejado no GitHub public roadmap.
Introdução
GitHub Actions oferece funcionalidades que permitem que você controle implantações. Você pode:
- Acionar fluxos de trabalho com uma série de eventos.
- Configurar ambientes para definir regras antes que um trabalho possa prosseguir e limitar o acesso a segredos.
- Usar a simultaneidade para controlar o número de implantações em execução por vês.
Para saber mais sobre a implantação contínua, confira "Sobre a implantação contínua com o GitHub Actions".
Pré-requisitos
Você deve estar familiarizado com a sintaxe de GitHub Actions. Para obter mais informações, 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 obter mais informações, 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".
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".
Note
concurrency
e environment
não estão conectados. O valor da simultaneidade pode ser qualquer regra; não precisa ser o nome de um ambiente. Além disso, se outro fluxo de trabalho usar o mesmo ambiente, mas não especificar a equivalência, esse fluxo de trabalho não estará sujeito a nenhuma regra de simultaneidade.
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 obter mais informações, 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 obter mais informações, confira "Visualizar o histórico de execução do fluxo de trabalho".
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 obter mais informações, confira "Sobre executores auto-hospedados" e "Usar 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 obter mais informações, 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 Enterprise Server 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.