Skip to main content

Limpar Feature Flags Após o Lançamento

Agende uma sessão única do Devin para remover um feature flag e seu código morto depois que o seu lançamento estabilizar.
AuthorCognition
CategoryAutomations
FeaturesSchedules
1

Agende a limpeza quando você publicar o flag

Você acabou de fazer o deploy de um novo fluxo de checkout atrás de enable_new_checkout. Ele está habilitado em produção, mas você quer uma semana de monitoramento antes de se comprometer a remover o código antigo. Em vez de criar um ticket que você vai esquecer, agende agora uma sessão única do Devin — enquanto o contexto ainda está fresco.Abra a página de criação de agendamento e defina o tipo como One-time. Escolha uma data após a sua janela de monitoramento (por exemplo, próxima sexta-feira às 9h). Selecione um canal do Slack para que sua equipe seja notificada quando a sessão for executada e o PR estiver pronto. Em seguida, cole seu prompt:
2

Deixe o prompt detalhado

Feature flags se escondem em lugares inesperados — arquivos de configuração, fixtures de teste, comentários, variáveis de ambiente. Quanto mais contexto você colocar no prompt, mais limpo será o resultado. Inclua:
  • Como seus flags funcionam — onde são definidos e como são verificados (por exemplo, useFeatureFlag('name') em React, isEnabled('name') em serviços de backend)
  • O que não deve ser alterado — o framework de flags em si vs. o flag específico (por exemplo, “não modifique src/lib/featureFlags/ — esse é o framework”)
  • Onde o código antigo e o novo estão — por exemplo, “o checkout antigo está em src/pages/checkout/legacy/, o novo fluxo está em src/pages/checkout/v2/”
  • Escopo da limpeza — comentários, docs, arquivos .env e configs de CI que fazem referência ao flag também devem ser limpos
Um prompt com esse nível de detalhe permite que o Devin rastreie todas as referências em uma única passada — sem necessidade de uma varredura posterior.
3

Revise o PR quando ele for aberto

Quando a sessão agendada for executada, o Devin rastreia todos os usos do flag na sua base de código, mantém o caminho de código habilitado, remove o caminho desabilitado e o código morto, limpa os testes e abre um PR. Você receberá uma notificação por e-mail quando ele estiver pronto.Um PR típico se parece com isto:
Removed feature flag: enable_new_checkout

- Deleted flag from src/config/featureFlags.ts (1 file)
- Removed 12 conditional branches across 7 files
- Deleted src/pages/checkout/legacy/ (4 files, 380 lines)
- Updated 3 test files — removed flag mocking, deleted old-path tests
- All 1,204 tests passing
Antes de fazer o merge, verifique com atenção se nenhuma lógica de negócio do caminho antigo deveria ter sido preservada — tratamento de erros, eventos de analytics ou fallbacks para casos extremos às vezes ficam dentro do branch “desabilitado”.