{"meta":{"title":"Implantando com GitHub Actions","intro":"GitHub Actions fornece controle detalhado sobre implantações com ambientes, grupos de concorrência e regras de proteção.","product":"GitHub Actions","breadcrumbs":[{"href":"/pt/actions","title":"GitHub Actions"},{"href":"/pt/actions/how-tos","title":"Instruções"},{"href":"/pt/actions/how-tos/deploy","title":"Implantar"},{"href":"/pt/actions/how-tos/deploy/configure-and-manage-deployments","title":"Configurar e gerenciar implantações"},{"href":"/pt/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments","title":"Gerenciar implantações"}],"documentType":"article"},"body":"# Implantando com GitHub Actions\n\nGitHub Actions fornece controle detalhado sobre implantações com ambientes, grupos de concorrência e regras de proteção.\n\n## Pré-requisitos\n\nVocê deve estar familiarizado com a sintaxe para GitHub Actions. Para saber mais, confira [Escrevendo fluxos de trabalho](/pt/actions/how-tos/write-workflows).\n\n## Acionando a sua implantação\n\nVocê 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`.\n\nPor exemplo, um fluxo de trabalho com os seguintes gatilhos é executado sempre que:\n\n* Há um push para o branch `main`.\n* Uma solicitação de pull direcionada ao branch `main` é aberta, sincronizada ou reaberta.\n* Alguém aciona ela manualmente.\n\n```yaml\non:\n  push:\n    branches:\n      - main\n  pull_request:\n    branches:\n      - main\n  workflow_dispatch:\n```\n\nPara saber mais, confira [Eventos que disparam fluxos de trabalho](/pt/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\n## Usar ambientes\n\nOs ambientes são usados para descrever um destino de implantação geral, como `production`, `staging` ou `development`. Quando um GitHub Actions fluxo de trabalho é 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](/pt/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments).\n\nVocê 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](#using-custom-deployment-protection-rules) neste artigo.\n\n## Usando concorrência\n\nA concorrência garante que apenas um único trabalho ou fluxo de trabalho que utilize o mesmo grupo de concorrência seja executado por vez. Você pode usar a simultaneidade para que um ambiente tenha no máximo uma implantação em andamento por vez. Para obter mais informações sobre a simultaneidade, confira [Controlar a simultaneidade de fluxos de trabalho e tarefas](/pt/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency).\n\n## Usando ambientes sem implantações\n\nPor padrão, quando um trabalho de fluxo de trabalho faz referência a um ambiente, GitHub cria um objeto de implantação para acompanhar a implantação. Você pode optar por não criar a implantação definindo `deployment` como `false` na configuração do ambiente. Os valores válidos são `true` (padrão) e `false`. Você também pode usar uma expressão, por exemplo `deployment: ${{ github.ref_name == 'main' }}`.\n\n```yaml\njobs:\n  test:\n    runs-on: ubuntu-latest\n    environment:\n      name: staging\n      deployment: false\n    steps:\n      - name: run tests\n        env:\n          API_KEY: ${{ secrets.API_KEY }}\n        run: echo \"Running tests with staging secrets\"\n```\n\nQuando `deployment` é definido como `false`:\n\n* O trabalho possui acesso completo a segredos e variáveis do ambiente.\n* Nenhum GitHub objeto de implantação é criado– o histórico de implantação do ambiente não é atualizado.\n* As regras de proteção do temporizador de espera ainda se aplicam, o trabalho aguarda a duração configurada.\n* Avaliadores obrigatórios ainda se aplicam, os avaliadores ainda devem aprovar antes que o trabalho seja executado.\n\nIsso é útil quando você deseja usar ambientes para:\n\n* **Organizar segredos** — agrupar segredos relacionados em um nome de ambiente sem criar registros de implantação.\n* **Controle de acesso** — restrinja quais ramificações podem usar determinados segredos por meio de políticas de ambientes para ramificações, sem a necessidade de rastreamento de implantações.\n* **Trabalhos de CI e teste:** referenciar um ambiente para sua configuração sem adicionar ruído ao histórico de implantação.\n\n### Interação com regras de proteção\n\nA propriedade `deployment` controla quais regras de proteção são aplicáveis:\n\n\\| Regra de proteção |\n`deployment: true` (padrão) | `deployment: false` |\n\\|----------------|------------------------------|---------------------|\n\\| **Nenhum** | Implantação criada, trabalho em execução | Sem implantação, execuções de trabalhos |\n\\| **Temporizador de espera** | Temporizador de espera imposto | Temporizador de espera ainda imposto |\n\\| **Revisores necessários** | Os revisores devem aprovar | Os revisores devem aprovar |\n\\| **Aplicativo de regras de proteção de implantação personalizadas** | Webhook do aplicativo foi enviado, precisa ser aprovado |\n**Tarefa falhou com erro** |\n\nAs regras de proteção de implantação personalizada (GitHub Apps) exigem que um objeto de implantação funcione. Se você definir `deployment: false` em um ambiente que tenha regras de proteção de implantação personalizadas, o trabalho falhará imediatamente com uma anotação ou mensagem de erro explicando que as regras de proteção do ambiente são incompatíveis com `deployment: false`. Ou remova `deployment: false` do fluxo de trabalho ou remova as regras de proteção de implantação personalizadas do ambiente.\n\nObserve que `concurrency` e `environment` não estão conectados. O valor da simultaneidade pode ser qualquer cadeia de caracteres; 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.\n\nPor 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`.\n\n```yaml\nname: Deployment\n\nconcurrency: production\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nVocê também pode especificar a concorrência no nível do trabalho. Isso permitirá que outros trabalhos no fluxo de trabalho continuem mesmo que o trabalho simultâneo esteja `pending`.\n\n```yaml\nname: Deployment\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    concurrency: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nVocê pode também usar `cancel-in-progress` para cancelar qualquer trabalho ou fluxo de trabalho em execução no mesmo grupo de concorrência.\n\n```yaml\nname: Deployment\n\nconcurrency:\n  group: production\n  cancel-in-progress: true\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nPara obter diretrizes sobre como escrever etapas específicas à implantação, confira [Como encontrar exemplos de implantação](#finding-deployment-examples).\n\n## Exibir o histórico de implantações\n\nQuando um GitHub Actions fluxo de trabalho é 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](/pt/actions/how-tos/deploy/configure-and-manage-deployments/view-deployment-history).\n\nSua organização pode coletar registros de implantação para todos os seus builds em um único lugar carregando dados no linked artifacts page. Confira [Sobre artefatos vinculados](/pt/code-security/concepts/supply-chain-security/linked-artifacts).\n\n## Monitoramento de fluxo de trabalho\n\nCada 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](/pt/actions/how-tos/monitor-workflows/use-the-visualization-graph).\n\nVocê 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](/pt/actions/how-tos/monitor-workflows/view-workflow-run-history).\n\n## Usando revisões necessárias nos fluxos de trabalho\n\nOs 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.\n\nPara obter mais informações sobre ambientes e aprovações necessárias, confira [Gerenciar ambientes para implantação](/pt/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments). Para obter informações de como examinar implantações com a API REST, confira [Endpoints da API REST para execuções de fluxo de trabalho](/pt/rest/actions/workflow-runs).\n\n## Usando regras de proteção de implantação personalizadas\n\n> \\[!NOTE]\n> Regras de proteção de implementação personalizada estão em prévia pública e estão sujeitas a alterações.\n\nVocê 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.\n\nAs regras de proteção de implantação personalizada são impulsionadas por 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](/pt/webhooks/webhook-events-and-payloads#deployment_protection_rule) e [Aprovação ou rejeição de implantações](/pt/actions/how-tos/deploy/configure-and-manage-deployments/create-custom-protection-rules#approving-or-rejecting-deployments).\n\nDepois 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.\n\nAs 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 de gerenciamento de serviços de TI (ITSM), resultado de verificação de vulnerabilidades 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.\n\n* 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.\n* 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.\n* 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.\n\nComo 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.\n\n## Rastreando implantações por meio de aplicativos\n\nSe sua conta pessoal ou organização no GitHub estiver integrada ao Microsoft Teams ou ao Slack, você poderá acompanhar implantações que usam ambientes por meio de Microsoft Teams ou Slack. Por exemplo, você pode receber notificações por meio do aplicativo quando uma implantação estiver pendente de aprovação, quando uma implantação for aprovada, ou quando o status de implantação for alterado. Para obter mais informações sobre como integrar Microsoft Teams ou Slack, consulte [Integrações de GitHub em destaque](/pt/integrations/concepts/featured-github-integrations#team-communication-tools).\n\nVocê também pode criar um aplicativo que usa webhooks de status de implantação e implantação para rastrear implantações.\nQuando 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 obter mais informações, consulte [Documentação do GitHub Apps](/pt/apps) e [Eventos e cargas de webhook](/pt/webhooks/webhook-events-and-payloads#deployment).\n\n## Escolher um executor\n\nVocê pode executar seu fluxo de trabalho de implantação em executores hospedados em GitHub ou em executores auto-hospedados. O tráfego de executores hospedados em GitHub pode vir de uma [ampla gama de endereços de rede](/pt/rest/meta/meta#get-github-meta-information). Se você estiver implantando em um ambiente interno e sua empresa restringir o tráfego externo em redes privadas, fluxos de trabalho GitHub Actions em execução em executores hospedados em GitHub podem não conseguir se comunicar com seus serviços ou recursos internos. Para superar isso, você pode hospedar seus próprios executores. Para saber mais, confira [Executores auto-hospedados](/pt/actions/concepts/runners/self-hosted-runners) e [Executores hospedados no GitHub](/pt/actions/concepts/runners/github-hosted-runners).\n\n## Exibindo um selo de status\n\nVocê 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.\n\n![Captura de tela de um selo de status de fluxo de trabalho. Da direita para a esquerda, são mostrados: o logotipo do GitHub, o nome do fluxo de trabalho (\"GitHub Actions Demo\") e o status (\"passing\").](/assets/images/help/repository/actions-workflow-status-badge.png)\n\nPara saber mais, confira [Adicionar um selo de status de fluxo de trabalho](/pt/actions/how-tos/monitor-workflows/add-a-status-badge).\n\n## Procurando exemplos de implantação\n\nEste artigo demonstrou recursos do GitHub Actions que você pode adicionar aos workflows de implantação.\n\nGitHuboferece modelos de fluxo de trabalho de implantação para vários serviços populares, como Azure Aplicativo Web. Para saber como começar a usar um modelo de fluxo de trabalho, confira [Usando modelos de fluxo de trabalho](/pt/actions/how-tos/write-workflows/use-workflow-templates) ou [navegue pela lista completa de modelos de fluxo de trabalho de implantação](https://github.com/actions/starter-workflows/tree/main/deployments). Confira também nossos guias mais detalhados de fluxos de trabalho de implantação específicos, como [Implantando Node.js em Azure App Service](/pt/actions/how-tos/deploy/deploy-to-third-party-platforms/nodejs-to-azure-app-service).\n\nMuitos provedores de serviços também oferecem ações no GitHub Marketplace para implantar em seus serviços. Para obter a lista completa, consulte [GitHub Marketplace](https://github.com/marketplace?category=deployment\\&type=actions)."}