Feature flags: o interruptor por trás de toda migração segura

Uma feature flag é uma condição avaliada em tempo de execução no seu código que decide qual comportamento roda, para que você possa mudá-lo sem fazer um novo deploy. Numa migração, as feature flags são o interruptor que manda os usuários para a implementação antiga ou para a nova, o que significa que uma release ruim geralmente pode ser desfeita trocando um valor, em vez de esperar um novo deploy.

Contei com isso na avanzzada, onde liderei a migração completa de uma plataforma que se candidata automaticamente a vagas de emprego pelos seus usuários. Nós migramos toda a arquitetura de uma stack legada para uma nova enquanto as pessoas continuavam usando a plataforma todos os dias. Este guia reúne o que eu gostaria de saber antes de começar.

O que são feature flags?

Uma feature flag, também chamada de feature toggle, é uma verificação no seu código do tipo “se o novo checkout estiver ligado, use-o; senão, use o antigo”. O importante é que a resposta não fica no código. Ela fica num arquivo de configuração, numa tabela do banco de dados ou num serviço de flags, então mudá-la não exige um novo deploy.

Isso separa duas coisas que as equipes costumam tratar como uma só: fazer deploy e liberar. Você pode colocar código novo em produção desligado, testá-lo com usuários internos e depois expô-lo aos poucos.

Uma flag pode ser avaliada de formas diferentes:

• Globalmente, para todo mundo de uma vez.
• Por usuário ou por conta.
• Para um percentual do tráfego.
• Por ambiente, como staging ou produção.

Como as feature flags tornam uma migração reversível?

Sem flags, cada etapa de uma migração é uma porta de mão única. Você faz o deploy, acompanha os dashboards e, se algo quebrar, faz rollback com um novo deploy, o que é lento e estressante. Com uma flag, o rollback é virar um interruptor.

Se é uma base de código que acabei de herdar, flags não são meu primeiro passo. Nas primeiras semanas assumindo um sistema, sigo uma ordem fixa: primeiro os acessos, depois o build, depois os caminhos do dinheiro, depois os riscos. Só quando consigo buildar e fazer deploy com confiança é que começo a adicionar interruptores.

A partir daí, minha regra é colocar o interruptor na frente de tudo antes de escrever código novo. A sequência fica assim:

1. Adicione a flag e direcione todo mundo para o caminho antigo.
2. Construa o caminho novo atrás da flag, desligado.
3. Quando possível, rode o caminho novo em segundo plano e compare os resultados com os do antigo, enquanto os usuários continuam recebendo o resultado antigo.
4. Ligue para os usuários internos.
5. Ligue para um grupo pequeno de usuários reais e acompanhe os erros e as métricas de negócio.
6. Amplie o grupo passo a passo até todo mundo estar no caminho novo.
7. Mantenha o caminho antigo durante uma janela de estabilidade e depois apague-o.

O que as flags não conseguem reverter

Uma flag reverte qual código roda. Ela não reverte dados. Se o caminho novo grava num banco de dados novo ou altera um schema, voltar a flag deixa o sistema antigo sem essas gravações, a menos que você mantenha os dois sincronizados. Planeje essa parte separadamente e tenha o máximo de cuidado nos caminhos do dinheiro, como pagamentos, cobrança e checkout. Como trabalhei no time de carrinho e checkout da Total Wine & More, trato esses caminhos com cautela redobrada: grupos pequenos, observação longa e uma definição clara do que significa “quebrado” antes de começar.

Quais tipos de flags existem: release, operacional, experimento e permissão?

Nem toda flag é igual, e misturá-las é o que bagunça os sistemas de flags. Uma forma comum de organizá-las:

Em migrações, as flags de release e as operacionais fazem a maior parte do trabalho. As de release movem o tráfego. As operacionais são o freio de emergência. As de experimento e de permissão importam menos, mas as de permissão são úteis para deixar um cliente parceiro testar o caminho novo primeiro.

A coluna de tempo de vida importa. Flags de release e de experimento devem ser temporárias. As operacionais e de permissão podem ficar, mas devem estar marcadas como permanentes para que ninguém fique na dúvida se pode apagá-las.

Vale mais construir feature flags ou usar um serviço?

As duas opções são razoáveis. A resposta certa depende de quem precisa virar as flags e de quantos sistemas as leem.

Quando construir por conta própria basta

Para uma aplicação e um punhado de flags, uma tabela no banco de dados ou um arquivo de configuração com uma pequena função auxiliar funciona. É barato e não traz um fornecedor novo. Como regra prática (estimativa minha, não um padrão), isso se sustenta enquanto só engenheiros mudam as flags e você raramente precisa de liberação por percentual.

Quando um serviço se justifica

Considere um serviço quando você precisar de:

• Liberação gradual por percentual e segmentação por atributos do usuário.
• Um log de auditoria de quem mudou o quê e quando.
• Que pessoas que não são engenheiras, como suporte ou produto, mudem flags com segurança.
• Que as mesmas flags sejam lidas de forma consistente por vários serviços.

As opções incluem produtos comerciais como LaunchDarkly e open source como Unleash, Flagsmith e GrowthBook. Confira preços e modelos de hospedagem atuais nos sites deles, porque isso muda.

Seja qual for a escolha, projete para falhar de forma segura. Nos meus projetos, se o armazenamento de flags estiver inacessível, o código cai para um padrão conhecido, normalmente o caminho antigo. Mantenha a avaliação rápida e faça cache dos valores, para que uma verificação de flag nunca seja o que deixa sua aplicação lenta ou a derruba.

Como evitar que as flags virem dívida técnica?

Toda flag cria pelo menos dois caminhos de código, e cada caminho extra precisa ser entendido, testado e, em algum momento, removido. Flags esquecidas depois de uma liberação são uma fonte comum de código confuso e bugs inesperados.

Estes hábitos mantêm isso sob controle:

• Dê a cada flag um dono e uma data de remoção no momento em que ela é criada, não depois.
• Crie a tarefa de limpeza junto com a flag, para que a remoção seja trabalho planejado. Eu abro esse ticket no mesmo pull request que adiciona a flag.
• Nomeie as flags pela finalidade, não por um rótulo vago de projeto.
• Evite aninhar flags dentro de outras flags. As combinações se multiplicam rápido.
• Remova o código antigo, não só a flag, quando o caminho novo estiver estável em 100% durante a janela que você definiu.
• Revise a lista com frequência. Ordenar as flags por idade mostra o que está abandonado.
• Teste os dois estados nos caminhos críticos, mas não tente testar todas as combinações.

Trate a remoção de flags como parte da migração, não como uma limpeza opcional. A migração não termina enquanto o caminho antigo e sua flag não forem removidos.

Como as feature flags funcionam com o padrão strangler fig?

O padrão strangler fig substitui um sistema no ar peça por peça. Uma camada de roteamento fica na frente do sistema antigo, e fatias de funcionalidade vão migrando para o novo ao longo do tempo, até o sistema antigo não ter mais nada para fazer.

As flags são o mecanismo de controle dessa camada de roteamento. O roteador ou proxy decide qual sistema atende determinada rota, e uma flag decide quem recebe a versão nova daquela fatia. Você pode mover um endpoint ou uma tela de cada vez, mandar um grupo pequeno pela versão nova e ampliar conforme a confiança cresce.

É o mesmo princípio que segui na avanzzada. A plataforma continuou no ar e os usuários seguiram dependendo dela todos os dias, então cada mudança precisava ser pequena o bastante para ser acompanhada e fácil de desfazer. Uma reescrita big-bang não oferece essa saída. Uma reescrita também tende a custar mais e levar mais tempo do que uma migração incremental, porque o sistema antigo precisa continuar rodando em paralelo de qualquer forma.

Quer uma segunda opinião sobre a sua migração?

Se você está planejando uma migração e quer validar como faria a liberação e o rollback, mande um e-mail para me@filipeeduardo.dev com o contexto. Fico feliz em trocar ideias e dizer o que eu verificaria primeiro.