Publicar uma aplicação copiando arquivos manualmente funciona até que alguém esqueça uma etapa, use uma dependência diferente ou não saiba qual versão está no servidor. Uma esteira de entrega reduz esse improviso ao transformar verificações e publicação em um procedimento reproduzível.
CI/CD deve produzir evidências de que uma alteração pode ser entregue e permitir identificar exatamente o que foi publicado. Automatizar um processo inseguro apenas faz o erro acontecer mais rápido. O desenho precisa considerar testes, credenciais, banco, aprovação e recuperação.
1. Defina o artefato que será entregue
Um artefato é a saída identificável do build: pacote estático, imagem de container ou distribuição executável. Associe-o à revisão do código, versão das dependências e configuração necessária. O mesmo código compilado em condições diferentes pode produzir comportamentos diferentes.
Prefira promover o artefato validado entre ambientes quando a arquitetura permitir. Se for necessário recompilar por diferenças de configuração, registre essa decisão e valide a saída efetivamente destinada à produção. Um teste sobre um pacote não comprova outro pacote gerado depois.
2. Separe ambientes e privilégios
Desenvolvimento, homologação e produção não devem compartilhar indiscriminadamente dados, chaves e permissões. A esteira que valida uma contribuição externa não precisa possuir a credencial de produção. Limite quem pode publicar e quais eventos podem iniciar essa publicação.
A referência de uso seguro do GitHub Actions trata de privilégios mínimos, segredos e código não confiável. Mesmo que a empresa utilize outra ferramenta, esses pontos ajudam a revisar os limites de confiança. Um arquivo de automação também é código capaz de produzir efeitos.
3. Organize verificações proporcionais ao risco
Comece por instalação reproduzível, verificação de tipos, análise estática e testes de regras essenciais. Acrescente testes de integração e contrato onde houver fronteiras relevantes. Uma mudança em cobrança exige verificações diferentes de uma alteração de cor.
| Etapa | Evidência esperada | Falha que deve impedir avanço |
|---|---|---|
| Dependências | Instalação consistente | Resolução inesperada |
| Código | Tipos e análise aprovados | Incompatibilidade ou erro conhecido |
| Regras | Cenários críticos válidos | Resultado de negócio incorreto |
| Build | Artefato gerado e identificado | Saída incompleta |
| Homologação | Jornada validada | Falha funcional ou de acesso |
| Publicação | Versão e saúde confirmadas | Serviço indisponível |
Não transforme quantidade de testes em objetivo isolado. Verificações que apenas repetem a implementação produzem confiança aparente. Priorize invariantes, casos de falha e comportamentos que realmente impediriam a operação.
4. Trate migrações de banco como uma entrega própria
Publicar código e alterar esquema são operações relacionadas, mas com riscos distintos. Verifique compatibilidade com a versão anterior, duração de bloqueios e estratégia para dados existentes. Uma implantação gradual pode manter versões diferentes da aplicação ativas ao mesmo tempo.
Retornar o código não desfaz automaticamente uma migração ou recupera dados apagados. Planeje mudanças aditivas, transição e retirada posterior quando adequado. O conteúdo sobre migrações de banco em produção aprofunda esse problema. A esteira deve reconhecer quando uma alteração exige uma janela ou supervisão específica.
5. Publique com verificação de saúde
Um processo iniciado não é prova de que a aplicação atende. Verifique uma rota de saúde e pelo menos uma jornada representativa: autenticação, consulta e operação controlada conforme o sistema. O teste deve distinguir dependências obrigatórias de recursos opcionais.
Evite usar um endpoint que sempre responde sucesso sem testar qualquer capacidade relevante. Por outro lado, uma verificação profunda demais executada a cada segundo pode gerar carga desnecessária. Separe prontidão, disponibilidade e testes sintéticos por finalidade.
6. Defina critérios para interromper e retornar
Antes do deploy, registre qual aumento de erro, latência ou falha de jornada exige interrupção. Determine quem decide e como comunicar o impacto. A decisão precisa considerar o volume observado: poucos acessos podem não produzir evidência suficiente para uma conclusão automática.
Um retorno confiável exige o artefato anterior, configuração compatível e procedimento testado. Se dados já foram alterados, pode ser necessário corrigir para frente ou executar uma compensação. Evite oferecer “rollback instantâneo” como promessa genérica para qualquer tipo de mudança.
7. Exemplo hipotético de publicação controlada
Uma empresa altera a regra de aprovação de pedidos. A esteira valida tipos, testes das alçadas e integração com o banco. O artefato recebe um identificador e é publicado na homologação. Um responsável executa cenários de aprovação, recusa e acesso de usuário sem permissão.
Em produção, a nova versão é acompanhada por erros e conclusões da jornada. Se o servidor responder, mas nenhum pedido puder ser aprovado, a implantação é considerada malsucedida. O critério é a função disponível ao usuário, não apenas o container em execução.
8. Preserve registros úteis
Registre autor da alteração, aprovação, artefato, horário, migrações e resultado. Proteja os logs contra exposição de segredos. A rastreabilidade deve permitir relacionar uma regressão a uma entrega sem reconstruir a história por mensagens de chat.
Revise duração da esteira e falhas instáveis. Um teste que falha aleatoriamente acaba sendo ignorado; trate a causa em vez de normalizar o botão “executar novamente”. O objetivo é uma evidência confiável que a equipe respeite.
Checklist de implantação
- Artefato ligado a uma revisão identificável.
- Dependências e comandos documentados.
- Segredos separados por ambiente e privilégio.
- Verificações de regras e integrações críticas.
- Migrações com compatibilidade e recuperação avaliadas.
- Saúde técnica e jornada funcional verificadas.
- Critérios de interrupção e responsáveis definidos.
- Procedimento de retorno ensaiado.
Checklist para usar com sua equipe
Baixe o checklist editável em CSV e registre responsáveis, verificações e observações da implantação.
Perguntas frequentes
Toda alteração deve entrar automaticamente em produção?
Não. A automação pode preparar a entrega e exigir aprovação para mudanças de maior risco. O processo deve refletir o contexto da empresa.
Docker é obrigatório?
Não. O requisito é uma entrega reproduzível, identificável e operável. Containers são uma opção, não uma condição universal.
Uma esteira elimina incidentes?
Não. Ela reduz classes de erro e melhora detecção e recuperação. Monitoramento e resposta continuam necessários.
Para profissionalizar a entrega do seu sistema, converse com a A2CR.
Autoria: Agência A2CR. Revisão editorial: 9 de novembro de 2026. Roteiro e exemplo elaborados pela A2CR; a fonte vinculada documenta controles da plataforma citada.
