Existe um laço que se retroalimenta em muito time.
Deploy é arriscado, então a gente faz menos vezes. Fazendo menos vezes, cada deploy acumula mais mudança. Mais mudança significa mais risco. Mais risco significa mais medo.
A saída não é ter mais cuidado. É quebrar o laço pelo outro lado: deploy pequeno e frequente é mais seguro, e a única forma de chegar lá é construir o que torna isso possível.
Por que deploy pequeno é mais seguro
Não é fé, é aritmética.
Um deploy com quarenta mudanças que quebra: você tem quarenta suspeitos, e provavelmente vários times envolvidos. A investigação leva horas.
Um deploy com uma mudança que quebra: você tem um suspeito. Reverte em dois minutos.
E a probabilidade de o deploy grande quebrar não é a mesma de um pequeno: é maior, porque interações entre mudanças são onde os problemas moram.
As cinco peças
1. Deploy que não derruba nada. Rolling update ou blue-green, com verificação de saúde de verdade. Um endpoint /health que devolve 200 sem verificar nada não serve: ele precisa confirmar que a instância consegue falar com o banco, com a fila e com o cache.
Diferencie prontidão de vivacidade. A instância pode estar viva e não pronta pra receber tráfego enquanto aquece cache ou abre pool de conexão. Confundir os dois faz o orquestrador reiniciar em laço no pior momento.
2. Migração compatível com a versão anterior. Essa é a que mais quebra deploy sem downtime, porque durante alguns minutos as duas versões do código rodam juntas.
Nunca renomeie, nunca remova, nunca adicione restrição no mesmo deploy que usa o campo. Adicione, backfill, migre a leitura, e remova semanas depois. Escrevi o passo a passo em migração de schema sem downtime.
3. Feature flag. Separar o deploy do código da liberação da funcionalidade é o que permite deploy pequeno de coisa incompleta.
if (await flags.enabled("novo-fluxo-cobranca", { userId })) {
return this.novoFluxo(dto);
}
return this.fluxoAtual(dto);Com isso, o código vai pro ar desligado, você liga pra 1% dos usuários, observa, e sobe. Um problema vira “desligar a flag”, que é instantâneo e não precisa de deploy.
O custo é dívida: flag que fica pra sempre é código morto com aparência de código vivo. Coloque prazo de validade e remova quando a funcionalidade estabilizar.
4. Rollback testado. Todo mundo tem rollback. Quase ninguém testou.
E rollback de código é fácil; o que trava é o banco. Se a migração não for reversível, voltar o código exige decidir o que fazer com o dado novo, sob pressão. É por isso que a regra da compatibilidade importa: ela é o que torna o rollback possível.
Faça um rollback em produção de propósito, num dia calmo, com uma mudança inofensiva. Descobrir que o procedimento está quebrado durante um incidente é a pior hora possível.
5. Observabilidade que responde rápido. Depois do deploy, três perguntas precisam ter resposta em menos de um minuto: a taxa de erro subiu, a latência subiu, e o volume das operações de negócio continua normal.
Essa terceira é a mais esquecida e a mais importante. Erro em zero e latência boa com o número de pedidos caindo pela metade é um deploy que quebrou alguma coisa silenciosamente.
O deploy de sexta
A discussão é famosa e mal colocada.
Se deploy de sexta assusta, o problema não é sexta. É que o time não confia no próprio processo, e nos outros dias o risco é o mesmo, só que tem mais gente acordada pra remediar.
Time com as cinco peças no lugar faz deploy quando quiser. Time sem elas não deveria fazer deploy grande em nenhum dia.
O que eu evitaria de verdade: deploy grande antes de um período em que ninguém vai olhar. Não pelo dia da semana, e sim porque o tempo entre quebrar e descobrir é o que determina o tamanho do estrago.
O detalhe que mais reduz ansiedade
Saber exatamente o que está indo.
Uma mensagem automática no canal do time listando os commits, quem fez cada um e o que muda. Custa quinze minutos de configuração e muda o comportamento coletivo: as pessoas passam a saber o que esperar, e quando algo estranho aparece, alguém reconhece a mudança relacionada.
O que medir
Quatro números dizem quase tudo sobre a saúde do processo.
Frequência de deploy, tempo entre commit e produção, porcentagem de deploys que causam incidente, e tempo médio pra restaurar.
Se a frequência for baixa e a taxa de falha alta, você está no laço do começo do texto. Se a frequência for alta e a taxa de falha baixa, o processo está bom, mesmo que pareça arriscado de fora.
O objetivo não é deploy perfeito. É deploy tão pequeno que errar seja barato.