O Que É um Post-Deployment Check? Verificando um Release ao Vivo
Um post-deployment check verifica se um release recém-implantado está de fato saudável no ambiente ativo, detectando um deploy ruim antes que os usuários o façam.
Um job de deploy terminar com sucesso significa apenas que o comando de deploy rodou, não que a aplicação está funcionando. Um post-deployment check fecha essa lacuna: depois que um release entra no ar, ele sonda o sistema em execução para confirmar que está saudável. Se o check falhar, o pipeline sabe que o deploy foi ruim e pode acionar um rollback automaticamente.
O que ele verifica
- O serviço está no ar e respondendo.
- Endpoints principais retornam resultados esperados (smoke tests).
- As health e readiness probes passam.
- As taxas de erro e a latência parecem normais.
Por que "deploy bem-sucedido" não basta
Um deploy pode ser aplicado sem problemas e ainda assim deixar uma aplicação quebrada: uma config ruim, uma migration falha, um secret ausente. Só exercitando o sistema ativo você descobre se o release de fato funciona. O post-deployment check é esse exercício.
Um exemplo rápido
Após o deploy, um check acessa GET /health e alguns endpoints críticos, confirma respostas 200 e observa a taxa de erro por dois minutos. Se algo parecer errado, ele falha e sinaliza um rollback.
Acionando o rollback
O verdadeiro poder de um post-deployment check é a automação: um check falho pode acionar o job de rollback sem um humano no circuito, reduzindo de minutos para segundos o tempo em que um release ruim fica no ar.
Checks e confiança
Post-deployment checks confiáveis permitem que as equipes façam deploy com mais frequência, porque cada release é verificado automaticamente. Eles transformam "faça o deploy e torça" em "faça o deploy e confirme", que é a base da entrega contínua segura.
Applying this to your pipeline
- Measure before changing. Most CI optimisation targets the wrong step because the slow one is assumed rather than timed.
- Cache what is expensive to produce and cheap to validate, and key the cache to the exact tool version.
- Fail fast: run the cheapest checks that can reject a change first, so an expensive job never starts on code that cannot pass.
- Prefer determinism over speed when they conflict. A fast pipeline nobody trusts gets re-run, which is slower than a slow one that is believed.
Principais conclusões
- Um post-deployment check verifica se um release está saudável depois de entrar no ar.
- "Deploy bem-sucedido" não é a mesma coisa que "a aplicação funciona."
- Um check falho pode acionar automaticamente um rollback para restaurar o serviço.