Publicar em produção não deveria dar medo

Existe um teste rápido para medir a saúde da entrega de software numa empresa: pergunte quando foi a última publicação em produção, e em que horário ela aconteceu.

Se a resposta for “mês passado, numa sexta à noite”, o problema não é a ferramenta.

O ciclo que se retroalimenta

Publicação rara acumula alteração. Lote grande carrega risco maior, porque quando algo quebra ninguém sabe qual das cinquenta mudanças foi a culpada.

Risco maior gera medo. Medo gera adiamento. Adiamento acumula mais alteração. É um ciclo que se fecha sozinho, e nenhuma ferramenta o quebra se o time não decidir reduzir o lote.

O ganho de CI/CD não é velocidade. É tamanho de lote: publicar uma alteração pequena por dia é menos arriscado do que cinquenta por mês, porque quando quebra fica óbvio o que foi.

O que a esteira assume

O ritual. Hoje publicar envolve uma sequência de passos que mora na cabeça de alguém. Uma etapa esquecida às dezoito horas de sexta vira incidente de fim de semana.

A verificação. Os testes que existem passam a rodar sempre, sem depender de alguém lembrar.

A rastreabilidade. Qual versão está em produção, qual alteração entrou nela, quem aprovou. Vira consulta em vez de arqueologia.

A volta. Voltar uma versão deixa de ser reconstrução sob pressão e passa a ser um comando.

O que ela não resolve

A esteira roda os testes que existem. Se não existe teste, ela entrega mais rápido um software igualmente frágil, e a automação só acelera a chegada do problema em produção.

Também não conserta processo de desenvolvimento desorganizado. Ela expõe: quando a publicação é automática, fica visível quantas vezes a alteração volta atrás.

Por isso a ordem importa. Primeiro teste automatizado, mesmo que cobrindo pouco, mesmo que só o caminho crítico. Depois a esteira.

O primeiro passo realista

Não é montar a esteira completa. É escolher um caminho crítico, escrever teste para ele, e fazer a publicação de homologação rodar sozinha.

Homologação primeiro porque o erro ali custa pouco, e é onde o time ganha confiança no mecanismo antes de apontá-lo para produção.

Depois disso, a conversa sobre publicar em produção sem janela combinada deixa de ser teórica. E costuma vir acompanhada de observabilidade, porque publicar mais vezes exige enxergar o efeito de cada publicação.

Agende um diagnóstico ou veja a frente de DevOps.