O que são Feature Flags ou Feature Toggles?

Sabe quando você está trabalhando naquele seu projeto pessoal em que basicamente você: escreve seu código, documenta, testa e faz seus commits, enquanto bebe seu café e ouve seu podcast favorito sem nenhuma preocupação com o impacto do seu código, do impacto do código que o seu colega está escrevendo, do prazo apertado e das outras várias tarefas te esperando no Trello... Sonho!?

Fonte: PicMix

Pois é, sabemos que o dia a dia de dev não é assim, tudo que botamos no ar tem um risco - como por exemplo, o sistema ficar indisponível em produção -, e cabe a nós achar formas de minimizá-lo, tanto o risco técnico quanto de negócio. Uma forma de fazer isso é usando Feature Flags, também chamadas de Feature Toggles. Você já ouviu falar?

O que são Feature Flag?

Feature Flag ou em tradução livre, alternância de recursos, é uma técnica que permite, dentre outras coisas: que seja possível ativar ou desativar uma funcionalidade em produção em tempo real sem fazer deploy, além de disponibilizar uma funcionalidade para uma parte dos seus clientes para fazer experimentação; desativar uma funcionalidade, sem precisar fazer rollback do código (o que exigiria outro deploy da aplicação); ativar uma feature somente para testes, definindo quem vai ver a feature (que podemos escolher somente um dev, por exemplo); permite que a pessoa QA (Quality Assurance ou analista de qualidade) faça testes na aplicação com a funcionalidade habilitada e desabilitada; e, por fim, facilita a remoção de funcionalidades que ninguém mais usa no seu sistema.

De forma resumida: a ideia do Feature Flag é economizar tempo e esforço de desenvolvimento do time, além de também diminuir riscos lançando funcionalidades de uma maneira mais incremental e evitando alterações manuais no sistema - que podem gerar erros.

Vou dar um exemplo prático, do dia a dia. Em uma empresa em que eu trabalhei, tínhamos que todo o mês mudar o produto que estava a venda no site e isso precisava estar no BackOffice também, isto é, no nosso sistema interno. Como todo o mês o site mudava e inseríamos algumas funcionalidades para essa troca de campanha, usávamos o Feature Flag (ou Feature Toggle), para ativar essa funcionalidade no backend, ou seja, a funcionalidade sempre estava disponível! E quando chegavam os dias da nova campanha, ativávamos o Feature Flag, inclusive fazendo um agendamento de dia e hora para ativação…isso nos poupava um bom tempo e energia.

Ainda que seja muito tentador - principalmente depois desse exemplo que eu trouxe - a ideia é que você não acumule várias flags no seu sistema, mas sim, que você e o seu time usem a funcionalidade de forma eficiente e com o tempo excluam as flags que já não são necessárias. E ainda digo mais, se vocês conseguirem criar as flags já pensando em manter por um período de tempo determinado, melhor ainda!

Como implementar?

Uma forma simples de construir essas Feature Flags é usar uma API (ou micro serviço), que vai consultar em um banco de dados quais Feature Flags seu sistema possui. Então o front-end, por exemplo, vai chamar essa API que vai ver no banco de dados correspondente, se existe essa flag e se ela está ativa ou inativa. Também existem plataformas pagas que oferecem esse serviço, com foco em teste a/b.

Ativação e desativação e a experiência do usuário

Vamos dizer que você e o seu time implementaram uma nova funcionalidade crítica (todos os usuários têm acesso a ela) e decidiram usar Feature Flags para diminuir o risco. Passadas algumas horas de uso, vocês descobrem que essa funcionalidade está quebrando várias outras do seu sistema e vocês decidem desativá-la. Nesse caso, o que acontece quando uma funcionalidade é ativada ou desativada em produção?

Como nosso foco é sempre o usuário, antes de implementar as Feature Flags, precisamos definir como a aplicação vai se comportar quando uma flag for desabilitada. Já imaginou se seu usuário está no meio de uma tarefa bem longa no seu sistema e do nada ela some e automaticamente ele é redirecionado para a sua tela inicial… Nada bacana né?!

Dependendo de quanto imprescindível seja remover uma funcionalidade, no momento da implementação de Feature Flags, pode ser definido que tipo de comportamento o sistema vai ter na sua desativação. Eu vejo dois caminhos, mas existem outros - e vale a conversa com seu time:

1º Caminho: Caso você não tenha urgência de desativar uma funcionalidade, é possível removê-la só quando o usuário fizer login novamente.

2º Caminho: Se você tem uma base de usuários usando uma funcionalidade crítica (com um bug terrível, por exemplo) e que pode estar causando um prejuízo ou tornando a aplicação insegura, você pode implementar o mecanismo de flag. No entanto, é necessário que o Backend avise ao Frontend (com mecanismos de comunicação em tempo real) que o mecanismo foi desativado e que o usuário seja direcionado para uma tela que informe a ele do que ocorreu. Não é um comportamento ideal, mas é melhor do que não avisá-lo e redirecionar para a home. Também é possível nesses casos mais críticos a funcionalidade desaparecer quando o usuário atualizar a tela - em uma próxima request.

Conclusão:

E aí, você já tinha ouvido falar nas Feature Flags? Já tinha implementado ou tinha tido algum tipo de experiência com essa técnica? Espero que esse texto tenha te ajudado, caso você ainda não conhecesse essa prática. Ela é muito útil e ajuda muito os times em vários sentidos, principalmente quando se trabalha com manutenção evolutiva. Como todas as práticas, discuta com seu time os benefícios e os trade offs da implementação no seu projeto e estudem as boas práticas relacionadas a esse assunto.

Se você quiser mais detalhes de como usar esse padrão e das aplicações dele, também sugiro a leitura desse texto do Martin Fowler, e se você curtir uma leitura técnica mais extensa, indico o livro Continuous Delivery do autor Jez Humble.

E se você quiser ver mais conteúdos sobre Feature Flags aqui na Alura, a Escola de Programação está no Discord e no fórum, e adoramos saber o que vocês estão querendo aprender com a gente!