Feature flags e releases progressivos: desacoplando deploy de lançamento
Existe uma confusão que custa caro em muitas engenharias: tratar deploy e lançamento como a mesma coisa. Deploy é colocar o código em produção. Lançamento é tornar um recurso visível para os usuários. Quando os dois estão amarrados, cada deploy vira um evento de alto risco, porque publicar o código significa, no mesmo instante, expor a funcionalidade a todo mundo. Se algo der errado, a única saída é um rollback do deploy inteiro, sob pressão.
As feature flags quebram essa amarração. Elas permitem publicar o código com o recurso desligado e ligá-lo depois, para quem você quiser, quando você quiser, sem novo deploy. Este guia mostra como usar flags para releases progressivos, kill switches e experimentos, e como evitar a armadilha que assombra quem abusa delas: a dívida de flags. O foco é o controle de lançamento, um tema distinto do pipeline e das estratégias de deploy do CI/CD.
O que é uma feature flag
Uma feature flag (ou feature toggle) é um interruptor no código que liga ou desliga um comportamento em tempo de execução, sem exigir um novo deploy. Em vez de o recurso aparecer no momento em que o código sobe, ele fica atrás de uma condição que você controla de fora, por um painel ou uma configuração.
if (flags.isEnabled("novo-checkout", usuario)) {
return renderNovoCheckout();
}
return renderCheckoutAtual();
O código das duas versões convive em produção, e a flag decide qual roda, para qual usuário, a cada requisição. Essa simples inversão muda tudo: o deploy deixa de ser o momento do lançamento e vira apenas o momento em que o código fica disponível para ser ligado.
Desacoplar deploy de lançamento
Com flags, o time faz deploy do código novo continuamente, com o recurso desligado, e o integra ao ramo principal sem medo. Isso libera práticas poderosas:
- Merge contínuo de trabalho incompleto. Um recurso ainda em construção pode ir a produção atrás de uma flag desligada, evitando branches longas que divergem por semanas.
- Lançamento por decisão de negócio, não de engenharia. Produto e marketing escolhem o dia e a hora de ligar o recurso, sem depender de uma janela de deploy.
- Rollback instantâneo sem novo deploy. Se o recurso novo dá problema, você desliga a flag em segundos, e o sistema volta ao comportamento anterior, sem reverter código.
Esse último ponto é decisivo. Desligar uma flag é ordens de magnitude mais rápido e seguro que reverter um deploy, e é o que transforma um incidente potencial em um não evento.
Releases progressivos: liberar aos poucos
A força maior das flags está em não ligar o recurso para todo mundo de uma vez. Em vez disso, você o libera de forma gradual e controlada, observando o comportamento a cada passo.
Rollout percentual
Você liga a flag para uma fatia pequena dos usuários, digamos 1%, e observa erros, latência e métricas de negócio. Se tudo está saudável, aumenta para 5%, 25%, 50% e enfim 100%. É o mesmo espírito do deploy canário, mas no nível do recurso, não da infraestrutura, e sob o seu controle direto. Um problema aparece atingindo poucos usuários, e você recua desligando a flag.
Targeting: para quem ligar
Flags permitem targeting fino, ligar o recurso para segmentos específicos:
- Usuários internos primeiro (dogfooding), para a equipe testar em produção antes de qualquer cliente.
- Beta testers que optaram por experimentar novidades.
- Um plano ou tier específico, ou clientes de uma região.
- Um tenant específico que pediu o recurso antecipadamente.
Kill switch
Um tipo especial de flag é o kill switch: um interruptor para desligar rapidamente um recurso problemático ou uma integração instável. Quando um serviço externo começa a falhar ou um recurso novo dispara erros, o kill switch corta aquele comportamento na hora, protegendo o resto do sistema sem exigir deploy nem rollback.
Experimentos e testes A/B
Como a flag já decide qual versão cada usuário vê, ela é a base natural para experimentação. Em um teste A/B, metade dos usuários recebe a versão A e a outra metade a versão B, e você compara métricas de negócio (conversão, engajamento, retenção) para decidir qual vence com dados, não com opinião. A mesma infraestrutura de flags que controla rollout serve para medir impacto, unindo engenharia e produto em torno de evidência.
Os tipos de flag e seus tempos de vida
Nem toda flag é igual, e confundir os tipos é uma fonte comum de bagunça. Cada uma tem um propósito e um tempo de vida esperado.
| Tipo de flag | Propósito | Tempo de vida |
|---|---|---|
| Release | Liberar um recurso novo aos poucos | Curto, remova após 100% |
| Experimento | Teste A/B para decidir com dados | Curto, remova após concluir |
| Operacional / kill switch | Desligar algo em emergência | Longo, parte da operação |
| Permissão / entitlement | Habilitar recurso por plano ou cliente | Longo, regra de negócio |
Entender o tempo de vida de cada flag é o que previne o maior problema desta prática.
A dívida de flags: o lado sombrio
Feature flags são fáceis de criar e fáceis de esquecer. Cada flag adiciona um if no código, um caminho a mais para testar e uma configuração a mais para manter. Quando um recurso já foi lançado a 100% e a flag de release continua lá, ela virou dívida técnica: código morto que confunde, ramos que nunca mais executam, e um risco real de alguém desligar por engano algo que já é permanente.
Um sistema com centenas de flags esquecidas é quase impossível de raciocinar: você não sabe mais quais combinações de flags são válidas, e o espaço de testes explode. Essa dívida de flags anula boa parte do benefício que as flags trouxeram.
A defesa é governança simples e disciplinada:
- Toda flag de release nasce com data de validade. Ela existe para ser removida depois do rollout completo, não para viver eternamente.
- Remover a flag faz parte da tarefa. O trabalho só termina quando o recurso está a 100% e a flag e o código do caminho antigo foram limpos.
- Revisão periódica das flags ativas. Um ritual regular que pergunta, de cada flag, se ela ainda tem motivo para existir.
- Distinga flags temporárias de permanentes. Kill switches e entitlements ficam; releases e experimentos saem. Trate cada grupo de acordo.
Flags são poder com responsabilidade
Feature flags dão à engenharia um controle que antes não existia: publicar sem lançar, liberar aos poucos, desligar em segundos, medir com experimentos. Bem usadas, elas transformam o lançamento de um salto arriscado em uma série de passos pequenos e reversíveis. Mal usadas, viram uma teia de interruptores esquecidos que ninguém entende. A diferença está na disciplina de tratar cada flag como algo que nasce com um propósito e, na maioria dos casos, com uma data para morrer. O interruptor é poderoso; a governança é o que o mantém sob controle.
Cada deploy no seu produto ainda é um evento de risco? Na ConstructorTI, implantamos feature flags com rollout progressivo, kill switches e governança de ciclo de vida, para você desacoplar deploy de lançamento e liberar recursos sem medo. Se você quer entregar com frequência e controlar o lançamento por decisão de negócio, fale com a nossa engenharia e receba um diagnóstico do seu processo de release.