O que é hotfix e como corrigir um bug urgente em produção

Diante de um bug urgente em produção, o reflexo de muita gente é abrir o editor e começar a corrigir na hora, direto na branch principal, sem saber ainda o que causou o problema. É compreensível: o cliente está ligando, o chefe está no canal, a adrenalina está alta. O custo costuma ser um segundo incidente, às vezes pior que o primeiro, causado pela própria correção apressada.

Hotfix é justamente a resposta organizada para essa situação. É uma correção pequena, feita fora do ciclo normal de entregas, para resolver um defeito em produção que não pode esperar a próxima versão planejada. Ele sai rápido, mas não sai de qualquer jeito.

Este verbete do glossário de programação do portal mostra o passo a passo que equipes experientes seguem, com os pontos em que cada etapa costuma dar errado.

Hotfix, patch e release: onde cada um se encaixa

• Hotfix: correção urgente de um problema em produção, aplicada assim que possível, fora do calendário de entregas.
• Patch: qualquer correção pequena e compatível, normalmente agrupada e entregue na próxima versão de manutenção.
• Release: a entrega planejada, com funcionalidades novas, correções e mudanças acumuladas.

A diferença está mais na urgência e no caminho do que no tamanho do código. Um hotfix costuma virar uma versão de patch: no Versionamento Semântico, uma correção compatível incrementa o último número, então a versão 2.4.0 com hotfix passa a ser 2.4.1. Quem consome sua biblioteca ou API entende, só pelo número, que nada mudou além da correção.

Exemplo concreto: o checkout de uma loja passa a cobrar frete em dobro depois do deploy das 18h. Isso é hotfix. Um botão desalinhado na página “Sobre” é patch para a próxima versão. Ninguém precisa ser acordado por ele.

Antes de corrigir: estancar e entender

1. Confirme o impacto. Quantos usuários, quais funcionalidades, desde quando. Olhe logs, métricas e o painel de erros antes de abrir o código.
2. Avise quem precisa saber. Um recado curto no canal do time (“checkout cobrando frete em dobro desde 18h, investigando”) evita que três pessoas investiguem a mesma coisa em paralelo.
3. Pergunte se dá para voltar atrás. Se o problema começou com o último deploy, desfazer esse deploy pode ser mais rápido e mais seguro do que escrever código novo. Desligar uma feature flag também conta.

Onde costuma dar errado: pular a etapa 3. Muita gente esquece que reverter também é uma correção. O comando git revert, descrito na documentação oficial do git revert, cria um novo commit que desfaz as mudanças de um commit anterior, sem reescrever o histórico. É seguro em branch compartilhada e devolve o sistema ao último estado bom em minutos.

Escrevendo o hotfix sem criar outro bug

4. Crie uma branch a partir do que está em produção, não da branch de desenvolvimento. Se a main já tem funcionalidades novas que ainda não subiram, partir dela leva junto código que ninguém testou.

   git switch -c hotfix/frete-duplicado v2.4.0

5. Reproduza o erro em ambiente local ou de homologação. Se possível, escreva um teste que falha por causa do bug. Ele vira a prova de que a correção funciona e impede que o problema volte.
6. Faça a menor mudança possível. Hotfix não é hora de renomear variáveis, atualizar dependência ou “aproveitar para melhorar” a função. Cada linha a mais é uma linha a mais que pode quebrar.
7. Peça revisão, mesmo com pressa. Um segundo par de olhos por dez minutos é barato perto de um segundo incidente. A revisão aqui é focada: o diff é pequeno e a pergunta é uma só, “isso corrige e não quebra mais nada?”.

Onde costuma dar errado: a etapa 6. O hotfix que deveria mudar uma linha chega com quarenta, porque “já que estava mexendo”. O revisor não consegue avaliar com calma, e um detalhe passa.

Subindo para produção e confirmando

8. Rode a esteira normal de testes. Pular o CI para ganhar cinco minutos é a aposta mais arriscada do processo.
9. Faça o deploy e gere a tag da versão (v2.4.1).
10. Verifique em produção com os mesmos sinais que denunciaram o problema: a métrica voltou ao normal? O erro sumiu do monitoramento? Um pedido de teste foi cobrado corretamente?

Se a sua empresa usa um fluxo com branches separadas para desenvolvimento e produção (como o Git Flow), há um passo extra que todo mundo esquece:

O hotfix precisa voltar também para a branch de desenvolvimento. Se você corrige só em produção, a próxima release sobe sem a correção e o bug reaparece.

Depois do incêndio: o que fazer no dia seguinte

O hotfix resolve o sintoma. A pergunta seguinte é por que o bug chegou à produção. Equipes maduras escrevem um relatório pós-incidente curto, sem caça a culpados. O livro de SRE do Google, no capítulo sobre cultura de postmortem, defende exatamente esse formato: focar no que falhou no processo, não em quem errou.

Um relatório útil cabe em uma página:

• O que aconteceu e quanto tempo durou.
• Como foi detectado (cliente reclamou ou o monitoramento avisou?).
• A causa raiz.
• O que muda para não repetir: um teste novo, um alerta, uma etapa a mais no deploy.

Esse último item é o que dá retorno. Se o frete dobrou porque ninguém testou o checkout com cupom, o teste de checkout com cupom entra na suíte. O hotfix seguinte, se vier, será de outro tipo de erro.

Hotfix toda semana é sintoma, não rotina

Um hotfix de vez em quando é normal em qualquer sistema vivo. Vários por semana indicam que algo antes do deploy está falhando: testes fracos, revisão apressada, deploys grandes demais ou falta de ambiente de homologação parecido com produção.

Nesse cenário, a correção estrutural é mexer no processo, não ficar mais rápido em apagar incêndio. Ferramentas que versionam a configuração e permitem voltar atrás com um clique ajudam bastante; o buildbase mostrou um exemplo disso na matéria sobre versões e aliases no Amazon Connect para reduzir rollback manual.

Quem pode aprovar e subir um hotfix?

Depende da empresa, mas o ideal é que a regra exista antes da crise. Times pequenos costumam permitir que qualquer dev suba o hotfix com uma aprovação. Empresas maiores, especialmente as reguladas (bancos, saúde), exigem registro de mudança e aprovação de alguém de plantão. Se você é júnior e nunca subiu um hotfix, pergunte hoje, com calma, qual é o processo, em vez de descobrir às 23h de uma sexta.

Hotfix precisa de teste automatizado?

Precisa, sempre que for possível escrever um em poucos minutos. O teste que reproduz o bug é o que garante que a próxima refatoração não traga o problema de volta. Se o teste exigir montar um cenário complexo demais para a urgência, suba a correção e crie a tarefa do teste para o dia seguinte, com prazo.

Posso fazer hotfix direto no servidor, editando o arquivo?

Tecnicamente dá, em alguns ambientes. Na prática, é a forma mais rápida de criar um servidor diferente do repositório. No próximo deploy, a sua correção é sobrescrita e o bug volta, agora sem ninguém lembrar que ele tinha sido “resolvido”. Mesmo com pressa, o caminho é commit, branch e deploy.

Na próxima vez que produção quebrar

Guarde a ordem: impacto, aviso, reverter se der, e só então código. Deixe o roteiro de dez passos fixado no canal do time ou no README do projeto. No meio da crise, ninguém lembra de nada; com a lista à mão, até o júnior que está de plantão pela primeira vez sabe o próximo passo.