Herdei um deploy de 50 minutos, e foi a melhor notícia do diagnóstico

Quando a Revin entrou nesse cliente, o deploy de produção levava cinquenta minutos e ninguém sabia dizer por quê. Demorei pra entender que o número não era o problema, era o sintoma. Conto o que estava embaixo, e por que um deploy lento custa muito mais caro do que parece.

Por Victhor Araújo

Victhor Araújo

A primeira vez que vi o deploy daquele cliente rodar até o fim, cronometrei sem querer. Cinquenta minutos. A gente tinha acabado de assumir um produto de logística que uma agência tocou por quase dois anos, com um time de quatro devs herdado junto, e eu estava ali só observando o ritual antes de mexer em qualquer coisa. Ninguém na sala achou cinquenta minutos estranho. Esse foi o detalhe que me incomodou, não o relógio.

O deploy saía duas vezes por semana, terça e quinta, sempre depois das seis da tarde, sempre com uma pessoa específica de plantão olhando o log subir. Se quebrasse no minuto quarenta e dois, voltava tudo pro começo. Numa sexta, um hotfix bobo de uma linha levou quase duas horas pra ir pro ar porque dois deploys entraram na fila e o segundo morreu no meio. Uma linha. Duas horas. E ainda assim o time tratava aquilo como clima: você não discute, só leva guarda-chuva.

Se você é founder e o seu time já normalizou alguma cerimônia lenta como "sempre foi assim", esse texto é sobre o seu produto, mesmo que o número aí seja outro.

O deploy de produção morava num script na máquina de um dev só. Quando ele tirava férias, o produto inteiro tirava férias junto.

O que cinquenta minutos escondem

O tempo do deploy raramente é o custo de verdade. O custo é o que aquele tempo impede o time de fazer. Com um deploy de cinquenta minutos que ainda por cima podia falhar no fim, o pessoal tinha aprendido a deployar pouco. Acumulava duas semanas de mudança num lançamento só, porque pagar o pedágio dava preguiça. E quanto mais coisa sobe junta, maior a chance de algo quebrar e mais difícil de descobrir o que foi.

A parte cara não tem nada a ver com os cinquenta minutos no cronômetro:

• Lançamento represado: feature pronta esperando dias por uma janela segura de deploy.
• Bug caro de achar: quando vinte commits sobem de uma vez, descobrir qual quebrou vira investigação.
• Medo de mexer: ninguém toca em código antigo perto da janela, então a dívida só engorda.
• Pessoa-gargalo: a tal pessoa de plantão não tirava férias de verdade fazia mais de um ano.

Somando, o cliente não tinha um problema de DevOps. Tinha um problema de velocidade de negócio fantasiado de problema técnico. Já escrevi por que medir isso com as métricas erradas só piora o diagnóstico, em DORA é o termômetro errado para time pequeno.

De quem é a culpa quando o deploy apodrece

O dev que rodava o deploy era ótimo, anote isso. O problema não nasceu nele. Nasceu no modelo de quem construiu antes: uma agência paga por feature entregue, contrato fechado por escopo. Numa relação assim, automatizar deploy é trabalho que não aparece na fatura. Ninguém vai gastar três dias montando um pipeline decente quando esses três dias podiam virar mais uma tela pra mostrar na reunião de status.

Chamar isso de descuido seria injusto. É o contrato funcionando exatamente como foi desenhado: paga-se pelo que se vê, e deploy bem feito ninguém vê. O fornecedor que vai embora quando o escopo fecha também não tem motivo pra se importar com o deploy daqui a um ano, porque ele não vai estar aqui pra rodar esse deploy. Foi assim que cinquenta minutos viraram normais. Cada sprint empilhou um pouco mais de manual em cima do manual, e ninguém cujo nome estava no contrato tinha incentivo pra parar e arrumar.

Quando dois deploys entram na fila e o segundo falha no minuto quarenta, o erro deixou de ser técnico. Virou processo.

O que a gente fez em três sprints e meio

Nada do que a gente fez foi heroico. Primeiro paramos de tratar o deploy como evento e passamos a tratar como rotina. Containerizamos a aplicação, que era um monólito Rails sem Docker, deployado por rsync, botamos o pipeline no GitHub Actions e fomos atrás dos dois gargalos óbvios da build: a suíte de testes rodava em série e a imagem reconstruía tudo do zero toda vez. Cache de camada e teste em paralelo derrubaram o grosso.

O deploy foi de cinquenta minutos pra nove, e de duas vezes por semana pra quantas vezes o time quisesse no dia. Esse nove é bonito demais pra ser média honesta, admito: peguei o melhor caso, com cache quente. Num deploy frio ainda dá uns treze. Mas treze minutos, várias vezes por dia, é outro planeta comparado a cinquenta, duas vezes na semana, com medo.

O efeito colateral foi o que mais importou. A tal pessoa-gargalo tirou três semanas de férias no fim daquele trimestre e o deploy continuou saindo sem ela. Ninguém precisou ligar pedindo socorro. Pela primeira vez em muito tempo, o produto não dependia de uma pessoa específica estar acordada.

Por que um squad que fica encara isso diferente

Um time que vai manter o que escreve trata deploy como assunto próprio, não como tarefa chata de outra pessoa. Se eu sei que daqui a um ano ainda vou estar aqui rodando esse mesmo deploy toda semana, eu não vou deixar ele em cinquenta minutos manual, porque isso me machuca antes de machucar o cliente. É essa diferença de incentivo que muda o código. E é exatamente o que um squad sênior embarcado coloca na mesa: gente que assume o produto como se fosse continuar nele, porque vai.

Esse tipo de coisa a gente costuma achar logo na primeira leitura do código, no Diagnostic Sprint, em geral nas duas primeiras semanas, antes de virar a crise da sexta às sete da noite. E se você quiser ver o padrão sendo desfeito em situação real, os cases contam melhor do que eu.

Voltando aos cinquenta minutos

Quando conto essa história, a parte que as pessoas guardam é o número, cinquenta caindo pra nove. Pra mim a parte que importa é outra. Ninguém naquela empresa decidiu conviver com um deploy de cinquenta minutos. Foi virando, sem decisão, sprint após sprint, sob um fornecedor que não tinha motivo nenhum pra olhar. Quase todo gargalo que a gente encontra é assim: não é uma escolha ruim que alguém fez, é uma escolha que ninguém fez e que foi acumulando enquanto o time estava ocupado entregando tela.

Se desconfia que tem um "sempre foi assim" rodando em segundo plano no seu produto, é bem mais barato descobrir agora do que numa sexta às sete da noite. Quando quiser, marca uma conversa.