Feature freeze e code freeze no desenvolvimento de aplicativos: essência, diferenças e papel

O que é um feature freeze?

Feature freeze é uma proibição temporária de adicionar novas funcionalidades à base de código, introduzida antes de um lançamento planejado. A equipe para de mesclar funcionalidades e se dedica a corrigir bugs, otimizar e polir o código existente. Os desenvolvedores finalizam funcionalidades incompletas apenas dentro do escopo de correções de bugs, sem expandir o escopo.

O feature freeze resolve o problema de funcionalidades em andamento (work-in-progress) que não chegam ao lançamento, mas já estão parcialmente mescladas na branch principal. Se novas funcionalidades continuarem a ser mescladas, o risco de regressão aumenta: cada nova integração requer retestar módulos já finalizados. Feature freeze fixa o escopo do lançamento, transformando-o de um alvo móvel em um conjunto estável de funcionalidades.

Um esclarecimento importante: feature freeze ≠ code freeze. Durante um feature freeze, correções de bugs, refatoração, atualizações de dependências e documentação são permitidas. Apenas novas funcionalidades visíveis ao usuário são proibidas — qualquer código que mude o comportamento do aplicativo da perspectiva do usuário. Verificação no code review: se um PR adiciona uma nova tela, botão ou método de API — é rejeitado até que o congelamento seja removido.

O que é um code freeze e como difere do feature freeze

Code freeze é uma prática mais rigorosa na qual todas as alterações no código são completamente proibidas. Mesmo correções de bugs não são permitidas a menos que sejam críticas. O code freeze é introduzido por um curto período (geralmente 24-48 horas) e garante que o build de lançamento seja montado a partir de um conjunto fixo de commits.

A diferença entre feature freeze e code freeze está no nível de controle. O feature freeze gerencia o escopo: exatamente o que será incluído no lançamento. O code freeze gerencia a qualidade: elimina o risco de introduzir um novo bug um dia antes do lançamento. Na prática, muitas equipes usam um modelo de duas etapas: 1-2 semanas antes do lançamento — feature freeze, 24-48 horas antes — code freeze. Code freeze é particularmente relevante para aplicativos móveis, onde o build precisa ser enviado à loja vários dias antes da data de lançamento planejada.

A exceção ao code freeze são correções de segurança para vulnerabilidades críticas (CVE com pontuação 9+). Tais alterações passam por um processo de emergência com revisão de código acelerada obrigatória e notificação à equipe. Todas as outras alterações são adiadas para o próximo ciclo de lançamento.

Feature freeze vs code freeze: comparação

A escolha entre feature freeze e code freeze depende da maturidade da equipe e da frequência de lançamentos. Equipes com CI/CD e feature flags podem precisar apenas de um code freeze de 24 horas, enquanto equipes com lançamentos mensais geralmente usam ambos os congelamentos sequencialmente.

Tipos de congelamentos: total, parcial e BAU-freeze

Além do feature freeze total e do code freeze, existem opções mais flexíveis. Partial feature freeze (congelamento parcial) bloqueia novas funcionalidades apenas em certos módulos — por exemplo, no módulo de pagamento ou no módulo de autorização, deixando os outros componentes abertos para alterações.

BAU-freeze (business as usual freeze) é uma opção de compromisso onde apenas grandes funcionalidades com volume de alterações acima de um certo limite (por exemplo, 500 linhas de código) são proibidas. Melhorias menores, ajustes de UI e correções de bugs continuam sendo mesclados. BAU-freeze é conveniente para projetos com entrega contínua, onde uma parada total do desenvolvimento por uma semana é economicamente inviável.

Existe também o conceito de deployment freeze (congelamento de implantação) — uma parada completa de implantações em produção, típica para temporada de feriados (férias de Natal, Black Friday). Durante este período, até mesmo hotfixes são bloqueados a menos que estejam relacionados à segurança. O deployment freeze geralmente dura 1-2 semanas e é coordenado a nível de empresa.

Quando introduzir um congelamento e quanto tempo dura

O momento ideal para introduzir um feature freeze é após a conclusão do código, quando todas as funcionalidades planejadas estão mescladas e passando pelo QA. O momento exato depende do ciclo de lançamento: para um sprint de duas semanas, o feature freeze é introduzido 3-4 dias antes da data de lançamento; para um lançamento mensal, 7-10 dias antes. Code freeze é introduzido 24-48 horas antes do horário planejado de compilação do lançamento.

A duração do congelamento deve ser a mínima suficiente para estabilizar o código. Um congelamento muito longo (mais de 2 semanas) desmotiva a equipe e cria um acúmulo de funcionalidades não mescladas, cada uma aumentando o risco de conflitos após a remoção do congelamento. Um congelamento muito curto (menos de 24 horas para um feature freeze) não permite tempo suficiente para testes e correções completos.

A prática recomendada é definir o congelamento não por data de calendário, mas pelo estado da base de código. O feature freeze é introduzido quando o número de bugs abertos para o lançamento excede um limite (por exemplo, 10 bugs críticos). Code freeze — quando o build passa com sucesso pelos testes de fumaça e suíte de regressão. Time-based freeze (data fixa) continua sendo o padrão para indústrias regulamentadas (fintech, medtech) onde a data de lançamento é aprovada por um regulador.

Automação de congelamentos via CI/CD e Git

O controle manual de congelamentos é uma fonte de erros: um desenvolvedor pode acidentalmente mesclar um PR que deveria esperar até que o congelamento seja removido. A automação resolve isso através de regras de proteção de branches do Git e pipelines CI/CD. No provedor Git (GitHub, GitLab, Bitbucket), são configuradas regras que bloqueiam mesclagens na branch de lançamento sem uma tag especial ou aprovação do release manager.

Pipeline CI/CD verifica o status do congelamento antes de compilar o build. No Jenkins, GitLab CI ou GitHub Actions, é adicionada uma etapa que lê um arquivo de configuração com o cronograma de congelamentos e rejeita builds se a data atual cair dentro do período de congelamento. Uma alternativa é uma feature flag no painel de administração que bloqueia a implantação em produção.

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "Feature freeze is active. PR blocked." && exit 1

O script de exemplo freeze-check.js lê um JSON com o cronograma de congelamentos da raiz do repositório. Se a data atual cair dentro do intervalo entre start_date e end_date para a branch especificada, o pipeline falha com uma mensagem de status do congelamento. Git branch protection adiciona uma segunda barreira: mesmo que o pipeline não tenha sido acionado, a regra não permite mesclar o PR sem aprovação.

Erros comuns ao implementar congelamentos

O primeiro erro é um congelamento sem critérios claros de remoção. A equipe congela o código, mas não define quais condições devem ser atendidas para descongelar: zero bugs críticos, suíte de regressão aprovada, aprovação do product manager. Sem critérios, o congelamento pode se arrastar por semanas. A definição de conclusão para o congelamento deve ser documentada e conhecida por todos os desenvolvedores.

O segundo erro é excesso de exceções ao congelamento. Cada exceção (“este PR não é uma funcionalidade, é dívida técnica”) desfoca o limite do congelamento. Se as exceções excederem 20% do fluxo normal de PRs, o congelamento não funciona. A equipe simplesmente renomeia funcionalidades como correções de bugs para contornar o bloqueio.

O terceiro erro é ignorar os release candidates. Se a equipe não constrói builds candidatos de lançamento e implanta diretamente em produção após o code freeze, o propósito do congelamento se perde: bugs são descobertos pelos usuários. O release candidate deve ser construído antes do code freeze, testado pelo QA e em staging, e somente após a confirmação da qualidade o code freeze é introduzido.

O quarto erro é o fator humano no controle manual. Um desenvolvedor pode esquecer de verificar o status do congelamento antes de mesclar, um release manager pode perder uma notificação. A única solução confiável é o bloqueio automático no nível do provedor Git ou CI/CD, eliminando o erro humano.