Implantando em produção com etapas de aprovação
Aprenda a promover compilações com segurança da preparação para a produção usando regras de proteção de ambientes do GitHub Actions, aprovações manuais e etapas de implantação.
Implantando em produção com etapas de aprovação é uma aula grátis de CI/CD with GitHub Actions & DevOps Pipelines no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de CI/CD with GitHub Actions & DevOps Pipelines, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de CI/CD with GitHub Actions & DevOps Pipelines inclui 4 aulas no total.
Por que a produção precisa de barreiras
A implantação contínua publica o código automaticamente, mas enviá-lo diretamente para a produção sem nenhum ponto de verificação é arriscado. Uma versão problemática pode afetar todos os usuários instantaneamente.
Uma barreira de aprovação é uma pausa deliberada na qual uma pessoa ou uma verificação automática confirma que uma implantação deve prosseguir.
- Reduz o alcance dos erros
- Cria uma trilha de auditoria de quem aprovou cada ação
- Permite separar os níveis de confiança de
stagingeproduction
Ambientes do GitHub
O GitHub Actions tem um recurso chamado Ambientes. Um ambiente, como production, pode ter seus próprios segredos, variáveis e regras de proteção.
Você faz referência a um ambiente em uma tarefa usando a chave environment. Essa é a base para adicionar barreiras de aprovação.
jobs:
deploy:
runs-on: ubuntu-latest
environment: production
steps:
- run: echo 'Deploying to production'Revisores obrigatórios
Nas configurações do repositório, em Configurações > Ambientes > production, você pode habilitar Revisores obrigatórios.
Quando uma tarefa tem como destino esse ambiente, a execução do fluxo de trabalho pausa e aguarda até que um dos revisores listados clique em Approve.
- É possível configurar até 6 revisores
- Qualquer aprovação, por padrão, libera a tarefa
- Dependendo das configurações, o aprovador não pode ser a pessoa que iniciou a execução
Um fluxo de trabalho completo com barreiras
Aqui, uma tarefa build é executada primeiro; depois, uma tarefa deploy depende dela por meio de needs e tem como destino o ambiente protegido production.
A implantação não será iniciada até que o revisor obrigatório a aprove na interface do Actions.
name: Deploy
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: echo 'build artifact'
deploy:
needs: build
runs-on: ubuntu-latest
environment:
name: production
url: https://myapp.example.com
steps:
- run: echo 'deploy to prod'Temporizadores de espera
Além dos revisores, os ambientes aceitam um temporizador de espera. Ele impõe um atraso de até 30 dias antes que uma implantação possa prosseguir.
Um temporizador de espera curto é útil como um período de resfriamento de segurança: ele dá à equipe uma janela para cancelar uma execução antes que ela chegue à produção.
Restrições de ramos para implantação
Os ambientes podem restringir quais ramos têm permissão para implantar. Para production, normalmente você permite apenas main ou tags de versão.
Isso impede uma implantação acidental na produção a partir de um ramo de funcionalidade.
- Ramos protegidos — apenas ramos com regras de proteção
- Ramos selecionados — uma lista explícita de permissões ou um padrão de tags
Segredos específicos do ambiente
Cada ambiente tem seus próprios segredos. Um ambiente production pode conter PROD_DB_URL, enquanto staging contém STAGING_DB_URL.
Os segredos definidos no ambiente ficam disponíveis apenas para tarefas que têm esse ambiente como destino, adicionando outra camada de isolamento.
steps:
- name: Deploy
env:
DB_URL: ${{ secrets.PROD_DB_URL }}
run: ./deploy.shAcompanhando o status da implantação
Definir uma url no ambiente adiciona um link clicável para a implantação na interface do GitHub e registra um objeto de implantação por meio da API de implantações.
Isso fornece um histórico visível: qual confirmação foi enviada para a produção, quando e por quem.
environment:
name: production
url: https://myapp.example.comAprovando uma execução pendente
Quando uma tarefa com barreira está aguardando, você verá uma faixa amarela de Review deployments na página da execução do fluxo de trabalho.
- Abra a execução na aba Actions
- Clique em
Review deployments - Selecione o ambiente e clique em
Approve and deployouReject
Você também pode deixar um comentário explicando a decisão.
Combinando várias barreiras
A barreira de produção mais robusta combina várias regras:
- Revisores obrigatórios (aprovação humana)
- Um temporizador de espera (período de resfriamento)
- Restrições de ramos (apenas
main) - Segredos do ambiente (isolamento)
A combinação dessas medidas cria um processo robusto de promoção de staging para production.
Ignorando barreiras com segurança
Às vezes, você precisa de uma correção emergencial. Em vez de remover as regras de proteção, considere um fluxo de trabalho de correção emergencial com escopo restrito, registros próprios e revisores mais rigorosos.
Nunca desabilite as barreiras permanentemente por conveniência — isso anula o objetivo do mecanismo de segurança.
Verificação rápida
Teste sua compreensão sobre barreiras de aprovação da produção.
Revisão
Você aprendeu a adicionar barreiras de aprovação para implantações na produção usando os Ambientes do GitHub.
- Use a chave
environmentpara direcionar a execução a um ambiente protegido - Revisores obrigatórios adicionam aprovação humana
- Temporizadores de espera adicionam uma janela de resfriamento
- Restrições de ramos e segredos do ambiente adicionam isolamento
Juntas, essas barreiras tornam segura e auditável a promoção de staging para production.
Aprenda CI/CD with GitHub Actions & DevOps Pipelines com um tutor de IA — grátis
Escreva e execute código real no seu navegador, obtenha ajuda instantânea de um tutor de IA 24/7 e continue de onde parou na web ou no app.
- Cursos
- 12
- Aulas
- 48
Perguntas Frequentes
A aula “Implantando em produção com etapas de aprovação” é grátis?
Sim — o texto completo de “Implantando em produção com etapas de aprovação” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de CI/CD with GitHub Actions & DevOps Pipelines, atualize para CoddyKit PRO. O curso de CI/CD with GitHub Actions & DevOps Pipelines inclui 4 aulas no total.
O que vou aprender em “Implantando em produção com etapas de aprovação”?
Aprenda a promover compilações com segurança da preparação para a produção usando regras de proteção de ambientes do GitHub Actions, aprovações manuais e etapas de implantação. Você pratica CI/CD with GitHub Actions & DevOps Pipelines com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar CI/CD with GitHub Actions & DevOps Pipelines?
Nenhuma experiência prévia é necessária. CI/CD with GitHub Actions & DevOps Pipelines no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.
Quanto tempo leva a aula “Implantando em produção com etapas de aprovação”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de CI/CD with GitHub Actions & DevOps Pipelines?
Sim. Cada aula de CI/CD with GitHub Actions & DevOps Pipelines inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Introdução à implantação contínua
- Implantação em um ambiente de preparação
- Variáveis de ambiente e segredos
- Implantando em produção com etapas de aprovação