O stack que ninguém atualiza não avisa antes de cobrar
Faz um tempo que venho notando o mesmo problema em produtos que parecem saudáveis por fora: o stack congela sem ninguém decidir congelar. Não existe a reunião de "vamos parar de atualizar". Existe uma sequência de sprints em que subir a versão de uma dependência sempre perde para uma tela nova, até o dia em que um clone limpo não builda mais e uma correção simples trava por causa de um runtime que saiu de suporte.
O que me fez escrever isto foi perceber que dá pra medir esse risco em uns vinte minutos, sem auditoria formal. São quatro perguntas que eu passei a fazer:
-
O runtime ainda tem suporte? Abra o endoflife.date e confira a versão de Node, Python, Ruby ou PHP em produção. Se a data de fim de suporte já passou, você roda algo que ninguém mais corrige lá fora.
-
Quantos majors atrás estão as cinco dependências mais usadas? Pegue as libs que aparecem em todo lugar do código. Duas versões maiores ou mais atrás já é um muro se formando.
-
Quando foi o último PR que só subiu dependência? Procure no histórico do git. Se precisa rolar meses para achar, upkeep não é rotina, é emergência adiada.
-
Um clone limpo builda em quanto tempo? Clone numa pasta nova, siga o README e cronometre. Passou de uma tarde, o ambiente virou conhecimento tribal.
O detalhe que mais me marcou num caso real: subir uma dependência para fechar uma vulnerabilidade conhecida puxou outra, que puxava outra, três anos de atualização adiada saindo tudo de uma vez. O custo de manter nunca aparece na fatura do mês. Ele espera acumular e cobra junto, sempre numa semana ruim.
A conclusão prática é chata, mas honesta: atualização de dependência precisa ser tarefa de rotina, um pouco a cada sprint, e não migração heroica de fim de semana. Um pouco por vez é barato. De uma vez, quando trava, é caro.
Escrevi a versão longa, com os números e o caso completo, no blog onde trabalho: https://revin.com.br/pt/blog/o-stack-que-ninguem-atualiza