Feature flags explicadas:lança às escuras e ativa depois

Feature flags explicadas: uma feature flag é um interruptor de ligar/desligar guardado na tua base de dados em vez de no teu código: a funcionalidade vai para produção às escuras — com deploy feito, mas invisível — e lanças mais tarde ao ligar o interruptor para um cliente beta, para 10% dos utilizadores ou para toda a gente. Sem novo deploy, sem alterar código, sem pânico no dia do lançamento.

Para um fundador a solo, as flags são a diferença entre o «lançamento» ser um deploy aterrador e o «lançamento» ser uma decisão que tomas enquanto bebes café. Eis como funcionam, as quatro formas como as vais usar de facto e os erros que as fazem sair pela culatra.

Feature flags explicadas: o que é realmente uma feature flag

Sem flags, controlar quem vê uma funcionalidade implica editar código. O remendo clássico é assim: «se o email do utilizador acabar no domínio do cliente beta, mostra a nova funcionalidade». Cada alteração a essa regra é uma alteração de código, e cada alteração de código é um deploy. A configuração vive em cinco sítios diferentes, nada tem histórico, e quem pode carregar no interruptor é quem souber onde está o remendo.

Uma feature flag passa essa decisão para os dados. A flag é um interruptor com nome — «new_dashboard: off» — guardado no teu sistema de definições, ao lado de coisas como o fuso horário e o tema. O teu código faz uma única pergunta: esta flag está ligada para este utilizador? Muda a resposta num painel e o produto muda de comportamento no mesmo instante — sem deploy. As flags vivem na mesma hierarquia que o resto das tuas definições: um valor global por omissão, que pode ser alterado por organização, que pode ser alterado por utilizador.

Lança às escuras, ativa com um interruptor

O grande desbloqueio mental é perceber que fazer deploy e lançar são dois acontecimentos diferentes, e são as flags que os separam.

Fazer deploy significa que o teu código chegou ao servidor. Lançar significa que os utilizadores o podem ver. Sem flags, são o mesmo momento — e é por isso que os lançamentos parecem perigosos e que os fundadores ficam semanas sentados em cima de trabalho terminado à espera do dia «certo». Com flags, fazes deploy da funcionalidade a meio, às escuras, dez vezes se quiseres. Vai à boleia em cada lançamento, testada em produção, visível só para ti. Quando estiver pronta, lançar é um interruptor — e se o deploy ainda te assusta, este é o padrão que elimina a maior parte do medo.

Também muda o teu marketing. Quando lançar não custa nada, deixas de apostar tudo num único grande dia e começas a lançar um fluxo de pequenas novidades controladas por flags — o motor por trás dos microlançamentos.

As quatro formas como os fundadores usam realmente as flags

Repara que estas são ferramentas de produto e de marketing tanto quanto de engenharia. O acesso beta é uma conversa de vendas («queres acesso antecipado?»). A disponibilização gradual é gestão de risco. Os testes A/B são otimização da página de preços. O botão de emergência é um seguro para o teu sono.

12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →

O argumento das 2h47 a favor das flags

Uma história verdadeira do meu próprio sistema em produção: 2h47 da manhã, o telemóvel vibra com um alerta de taxa de erros. Um endpoint a falhar, utilizadores afetados. Duas opções — depurar meio a dormir, ou reverter para a versão anterior com dois cliques. Reverti. Resolvido em 90 segundos, de volta à cama, depurei como deve ser de manhã.

Uma reversão é um instrumento grosseiro: reverte tudo o que ia nesse lançamento — a funcionalidade avariada e as três boas que saíram com ela. Uma feature flag é cirúrgica. Se a coisa avariada estiver atrás de uma flag, desligas só essa funcionalidade e deixas o resto do lançamento a funcionar. No melhor cenário, nem chegas a enfrentar a escolha das 2h47: a disponibilização gradual fez com que só 10% dos utilizadores vissem o bug, a flag foi desligada e a maioria dos teus clientes nunca soube que alguma coisa aconteceu.

Os erros que fazem as flags sair pela culatra

• Sem valor por omissão. Acrescentas uma flag nova mas nunca defines o que significa para os utilizadores existentes — recebem uma resposta indefinida e a app porta-se mal de formas que não consegues reproduzir. Cada flag sai com um valor por omissão explícito.
• Sem histórico. O produto começa de repente a comportar-se de outra forma e ninguém sabe quem mudou o quê, nem quando. Cada alteração de uma flag deve registar quem, o quê, o valor antigo, o valor novo e a hora — flags sem histórico são um pesadelo para depurar.
• Qualquer pessoa pode mudar qualquer coisa. As flags são controlos de produção. Mudar uma flag ao nível da organização deve exigir permissões de administrador, exatamente como mudar a faturação da organização.
• Verificar a flag com uma consulta à base de dados em cada pedido. As verificações de flags acontecem constantemente; têm de vir de uma cache que se atualiza quando a flag muda, e não de uma consulta nova sempre que uma página carrega.

Precisas de flags desde o primeiro dia?

Mais cedo do que pensas. Não precisas de um produto de flags sofisticado — uma tabela de flags na tua própria base de dados, gerida a partir de um ecrã de administração simples, é o padrão que faz isto funcionar a qualquer escala. Faz parte do teu sistema de definições, que a IA constrói depressa a partir de uma boa especificação; o mecanismo das flags em si são umas horas de trabalho, não um projeto.

A recompensa começa logo na tua primeira funcionalidade assustadora. Da primeira vez que lançares algo às escuras numa terça-feira, o testares em produção a semana inteira e o «lançares» na segunda-feira seguinte carregando num interruptor — vais perguntar-te como é que alguém constrói sozinho sem isto.

O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →

Perguntas frequentes

Qual é a diferença entre uma feature flag e uma definição?

Uma definição guarda uma preferência — fuso horário, tema, moeda. Uma feature flag guarda uma decisão sobre disponibilidade: esta funcionalidade está ligada, e para quem? Vivem no mesmo sistema hierárquico (valor global por omissão → alteração por organização → alteração por utilizador), e é por isso que o mecanismo das flags costuma ser construído como parte do teu sistema de definições.

Qual é a diferença entre uma feature flag e uma reversão?

Uma reversão repõe todo o teu deploy na versão anterior — eficaz, mas leva as alterações boas juntamente com as más. Uma flag desliga uma funcionalidade específica e deixa tudo o resto a funcionar. Queres as duas: as reversões como travão de emergência, as flags como o controlo de precisão a que recorres primeiro.

As feature flags tornam a app mais lenta?

Não, se estiverem em cache. A verificação da flag corre constantemente, por isso a resposta tem de vir de uma cache que se atualiza quando uma flag muda — nunca de uma consulta nova à base de dados a cada carregamento de página. Bem feito, o custo é praticamente zero.

Um fundador não técnico consegue gerir feature flags?

É exatamente essa a ideia. As flags tiram as decisões de lançamento do código e põem-nas num painel: decides quem vê o quê, e quando, sem tocar num deploy. Tu diriges a disponibilização — 10% hoje, toda a gente na segunda-feira — da mesma forma que agendarias uma newsletter.