Hotfix no desenvolvimento de aplicativos: essência, mecanismo e como aplicar

O que é um hotfix e quando é necessário?

Um hotfix (correção rápida) é um patch para a versão de produção de um aplicativo lançado fora de fila para corrigir um problema crítico. Um hotfix é entregue aos usuários em horas, não em dias, e é destinado exclusivamente a situações em que o aplicativo está indisponível, perdendo dados ou comprometendo a segurança do usuário.

Cenários típicos para um hotfix: falha na inicialização em determinados dispositivos (regressão após o último lançamento), vazamento de dados pessoais devido à autorização incorreta, integração de pagamento quebrada (perda de receita), violações de conformidade GDPR/CCPA. Todas essas situações têm gravidade P0 ou P1 na classificação de incidentes. Tarefas planejadas — otimização, refatoração, novas telas — nunca são feitas via hotfix.

Uma regra importante: um hotfix contém um número mínimo de alterações (1–2 arquivos, 10–20 linhas de código). Quanto menor o diff, menor o risco de introduzir um novo bug. Se corrigir o problema exigir alterar a arquitetura ou adicionar um novo módulo — isso não é um hotfix, mas um lançamento de emergência que requer revisão de código completa e QA.

Como um hotfix difere de um lançamento normal

As principais diferenças entre um hotfix e um lançamento planejado são velocidade, escopo de alterações e nível de teste. Um lançamento planejado pode incluir dezenas de recursos, passar por um ciclo completo de QA (testes de regressão + integração + UI) e levar de 1 a 2 semanas desde o congelamento do código até a implantação. Um hotfix inclui uma ou duas correções, passa por revisão acelerada (2 aprovações em vez de 3) e testes smoke mínimos.

Da perspectiva do processo Git, um hotfix é criado a partir de uma tag de lançamento, não da branch develop. Isso garante que apenas as alterações necessárias para corrigir o problema sejam incluídas no hotfix, sem puxar acidentalmente recursos inacabados de develop. Após a implantação, o hotfix é mesclado de volta em main e develop (via cherry-pick ou merge).

Comparação entre lançamento planejado e hotfix

Importante: nem toda tarefa urgente é um hotfix. Se um gerente disser “precisamos urgentemente adicionar um botão” — isso não é um hotfix, é uma mudança de prioridade. Um hotfix real é determinado pela gravidade para o usuário, não pela urgência para os negócios. O critério: se o aplicativo não está travando e os dados não estão vazando — a tarefa espera um lançamento planejado.

Processo de hotfix: da detecção à implantação

O primeiro passo ao descobrir um problema crítico é o triagem — uma avaliação rápida da gravidade. O engenheiro de plantão confirma o bug, verifica logs e relatórios de falhas e determina se o problema é uma regressão do último lançamento ou um bug antigo. Se a gravidade for P0 — o pipeline de hotfix é acionado. O estágio de triagem não deve levar mais de 15 minutos.

O segundo passo é criar uma branch a partir da última tag de lançamento (v2.5.0 → hotfix/v2.5.1). O desenvolvedor faz a correção mínima, faz commit com o prefixo HOTFIX na mensagem, envia e abre um PR com o rótulo [HOTFIX]. Revisão de código fast-track: dois revisores são atribuídos automaticamente via CODEOWNERS, tempo de revisão — no máximo 30 minutos. Se não houver revisão em 20 minutos — o revisor é ignorado e o próximo é atribuído.

O terceiro passo é build e deploy via CI/CD. O pipeline de hotfix difere do normal: testes de integração longos (que levam horas) são pulados, apenas a suíte smoke é executada (10–15 cenários críticos, 5–10 minutos). Após o deploy: monitoramento da taxa de falhas, taxa de erros, latência da API — por 30 minutos. Métricas DORA para hotfixes: o tempo médio de recuperação (MTTR) deve ser inferior a 1 hora.

# .github/workflows/hotfix-deploy.yml
name: Hotfix Deploy Pipeline
on:
  pull_request:
    types: [labeled]
    branches: [hotfix/*]

jobs:
  hotfix-checks:
    runs-on: ubuntu-latest
    if: contains(github.event.label.name, 'hotfix-critical')
    steps:
      - uses: actions/checkout@v4
      - name: Validate diff size
        run: bash .github/scripts/diff-check.sh 30
      - name: Build
        run: ./gradlew assembleRelease
      - name: Smoke test
        run: ./gradlew smokeTest
      - name: Deploy to staging
        run: fastlane deploy_staging
      - name: Approve & deploy to production
        if: success()
        run: fastlane deploy_production
        env:
          HOTFIX_MODE: true

Principais otimizações neste pipeline: verificação de diff (não mais de 30 linhas), pulo de testes de integração, implantação automática em staging e production se o teste smoke for bem-sucedido. HOTFIX_MODE variável de ambiente que ativa verificações adicionais em tempo de execução — por exemplo, registro estendido para diagnóstico rápido de problemas.

Branches hotfix no Git: a estratégia correta

A estratégia para trabalhar com branches hotfix é descrita no Gitflow Workflow. A regra principal: uma branch hotfix é criada a partir da última tag de lançamento (git checkout -b hotfix/v2.5.1 tags/v2.5.0), não de develop ou main. Isso garante que o hotfix seja baseado no mesmo estado de código atualmente em produção e não puxe alterações inacabadas de develop.

Após a conclusão da correção, a branch hotfix é mesclada em main (ou master) e develop. Em main — um commit de mesclagem normal com uma nova tag de patch (v2.5.1). Em develop — uma mesclagem ou cherry-pick, dependendo da política da equipe. Se develop contiver mais alterações que main, recomenda-se fazer cherry-pick do commit hotfix específico para evitar conflitos. GitFlow recomenda mesclar o hotfix em main primeiro e, em seguida, mesclar main em develop.

# Criar branch hotfix da última tag de lançamento
git checkout -b hotfix/v2.5.1 tags/v2.5.0

# Aplicar a correção
git commit -m "HOTFIX: Fix crash on Android 14 notification permission"

# Mesclar em main e marcar o lançamento
git checkout main
git merge --no-ff hotfix/v2.5.1
git tag -a v2.5.1 -m "Hotfix release v2.5.1"

# Mesclar em develop também
git checkout develop
git merge --no-ff hotfix/v2.5.1

# Limpar a branch temporária
git branch -d hotfix/v2.5.1

Importante: se o hotfix corrigir um bug existente na branch develop atual (o bug foi introduzido vários sprints atrás), então após mesclar o hotfix em main e develop, develop já contém a correção. Se o bug foi introduzido apenas na branch de lançamento (um erro acumulado via cherry-pick), então a correção pode não ser necessária em develop. A análise de causa raiz ajuda a determinar se um cherry-pick em develop é necessário.

Riscos dos hotfixes e como minimizá-los

O principal risco de um hotfix é introduzir um novo bug mais grave devido à pressa. De acordo com um estudo da Stripe (2021), 15% dos hotfixes causam regressão e exigem um segundo hotfix. É uma lei da ironia: quanto mais rápido corrigimos, maior a chance de cometer um erro. A minimização de riscos é alcançada limitando estritamente o tamanho do diff (não mais de 30 linhas) e testes smoke automáticos obrigatórios.

O segundo risco é o acúmulo de dívida técnica. Se uma equipe usa regularmente hotfixes em vez de lançamentos planejados, a base de código se degrada: os commits de hotfix não passam por refatoração, soluções temporárias não são substituídas por soluções adequadas, a documentação não é atualizada. Verificação de saúde: se hotfixes são lançados mais de uma vez por mês — o processo de lançamento precisa ser revisado.

O terceiro risco é psicológico. Hotfixes regulares esgotam a equipe: os desenvolvedores de plantão estão sob estresse constante, a revisão de código se torna uma formalidade (todos querem ir mais rápido) e a cultura de qualidade diminui. Uma frequência normal de hotfixes para uma equipe madura é de 1–2 por trimestre. Se for maior — o problema não está nos hotfixes, mas na qualidade dos lançamentos planejados.

O que fazer após um hotfix

Após implantar um hotfix e estabilizar as métricas, é realizada uma retrospectiva post-mortem sem culpa. A equipe responde a quatro perguntas: o que aconteceu, por que as verificações não pegaram o bug, o que foi feito para corrigi-lo e como evitar a recorrência. O post-mortem é realizado dentro de 24–48 horas após o hotfix, enquanto os detalhes ainda estão frescos. Cultura sem culpa é um princípio chave: discutem-se processos, não pessoas.

O resultado do post-mortem são itens de ação concretos com responsáveis e prazos. Itens de ação típicos: adicionar um teste de unidade para o caso perdido, expandir a suíte de testes smoke, melhorar o monitoramento (adicionar um alerta sobre a métrica), atualizar o runbook para incidentes semelhantes. Itens de ação devem ser concluídos antes do próximo lançamento planejado.