Feature Toggle

Na minha carreira eu consegui ajudar duas startups diferentes na implementação de feature toggle. Uma delas, a Arquivei, um SaaS B2B, usamos em diversas ocasiões, tanto no lançamento de features com rollouts quanto na migração da AWS para o GCP. Na outra, a Creditas, uma fintech, usamos no lançamento de alguns produtos internos. Em ambas as ocasiões usei o Split como ferramenta (falarei sobre essa escolha ao longo do artigo).

O meu objetivo nesse artigo não é o de explicar no detalhe como uma feature toggle funciona e nem divagar sobre os benefícios do uso de feature toggles. Eu espero responder algumas dúvidas para as empresas sobre como usar feature toggles. Espero responder a seguintes dúvidas até a conclusão deste artigo:

• Como implementar feature toggles sem atribuir mais uma responsabilidade ao desenvolvedor?
• Como fazer um lançamento mais preciso sem aumentar os riscos?
• Como dar um pontapé (setup básico)?
• Como instalar feature toggle em uma aplicação super escalável?
• Como começar a usar feature toggle: pagando, usando um lib open-source ou construindo a minha ferramenta do zero?
• Como posso fazer deploy as 17:59 em uma sexta-feira 13?

O que é uma feature toggle?

Indo direto ao ponto, feature toggle é uma estratégia que nos permite fazer integração contínua. Essa estratégia consiste em habilitar e desabilitar recursos e funcionalidades em um sistema sem alteração de código e em tempo real (ou muito próximo disso).

Com uma feature toggle funciona

Simplificando a estratégia, o seu código será segmentado em um condicional [if-else] que definirá se uma feature deve ou não estar ligada. Com isso, em um “painel administrativo”, é possível definir se essa feature deve ou não estar ligada em tempo real. Esse é o funcionamento básico de uma feature toggle. Com isso, podemos soltar um deploy com mais continuidade e ligar recursos e funcionalidades somente quando desejado.

Em muitos momentos haverá dúvida sobre qual o domínio da feature toggle. O que o diferencia de um sistema de permissão? Isso está muito ligado ao dinamismo e a longevidade do recurso que será controlado. Recomendo a leitura do artigo do Martin Fowler sobre feature toggle. Este artigo explica precisamente o que é uma feature toggle e como fazer essa distinção entre feature toggles, toggles de permissão, toggles operacionais e toggles experimentais.

Definições

O que é uma feature? O que define uma feature? A tradução literal é funcionalidade? O que de fato significa "funcionalidade"? O que é um deploy? Para que serve um deploy? Vamos começar dando nome aos bois.

Feature: aportuguesamento da palavra.

Rudemente nós usamos feature para se referir a qualquer coisa. Uma correção de bug pode ser uma feature, uma mudança numa chave de tradução pode ser uma feature e até mesmo um produto novo pode ser uma feature, certo?

O ideal é entendermos qual o real significado da palavra feature para não chamarmos tudo de feature. Se não fizermos isso é bem capaz de corrigirmos um bug e lançar essa correção como se fosse uma feature, e o que é pior, comemorar esse lançamento como uma feature. 👀

Convenhamos, esse é um problema de toda empresa. Em algum momento você chegou a se perguntar. "Isso é um bug ou é uma feature?" 🤔

Definição de Feature

1. a. Archaic: the make, shape, form, or appearance of a person or thing [arcaico: a marca, ou a forma, ou o formato ou aparência de uma pessoa, ou coisa]
   b. Obsolete: attractive appearance; physical beauty [obsoleto: aparência atrativa, beleza física]
2. a. the form or look of the face; facial appearance [a forma ou aspecto de uma face; aparência facial]
   b. any of the parts of the face, as the eyes, nose, mouth, etc. [qualquer parte de uma cara, os olhos, o nariz, a boca, etc.]
3. a. distinct or outstanding part, quality, or characteristic of something [uma parte distinta ou marcante, qualidade ou característica de alguma coisa]
4. a. prominently displayed or publicized attraction, as at an entertainment or sale [uma atração publicada ou divulgada com destaque, como um entretenimento ou venda]

A definição formal tende a deixar um pouco turva o real significado da palavra, então vamos explorar um pouco além da definição…

Significado de Feature

1. A feature of something is an interesting or important part or characteristic of it. [uma feature de alguma coisa é uma parte interessante ou importante, ou característica da mesma]
2. Your features are your eyes, nose, mouth, and other parts of your face. [as suas features são seus olhos, seu nariz, sua boca e outras partes do seu rosto]

A partir da definição formal e do seu significado, conseguimos deduzir que uma feature é aquilo que envolve uma aparência visual, que é característico, que é um destaque. O erro mais comum é fazermos a tradução literal para funcionalidade enquanto o correto seria característica.

Isso certamente vai causar um desconforto quando pensar: "Então feature só faz sentido no front-end?". A minha resposta é não. Apesar da tradução explicitar que uma feature é uma característica física, no software (que é abstrato por natureza) é aceitável usar a palavra feature para remeter as características do sistema e não somente o seu visual.

Definição de Deploy

1. Military [militar]
   a. to spread out (troops, etc.) so as to form a wider front [espalhar-se (em tropas, etc.) para formar uma frente mais ampla]
   b. to station or place (forces, equipment, etc.) in accordance with a plan [estacionar ou colocar (forças, equipamentos, etc) de acordo com um plano]
2. to spread out or place like military troops [espalhar ou colocar como tropas militares]

Novamente, vamos explorar um pouco além da definição…

Significado de Deploy

1. To deploy troops, weapons, or resources means to means to make them ready to be used. ["deploiar" tropas, itens ou recursos significa deixá-los prontos para o uso]
2. If you deploy something or if it deploys, you use it effectively or it works effectively. [se você "deploia" alguma coisa ou isso se "deploia", você usa isso efetivamente ou isso funciona efetivamente]

Com isso conseguimos concluir que o deploy é tornar os recursos disponíveis e prontos para uso. O maior problema é nos referimos a deploy como lançamento enquanto que o correto é deixar pronto para uso. Isso quer dizer que podemos lançar uma feature que está pronta para uso, mas nenhum usuário a usa de fato.

Usando um paralelo com a terminologia militar, deploy a troop [deploiar uma tropa] não significa que ela está na batalha, mas sim que ela está pronta para a batalha. Usando outro paralelo com a Nasa é o lançamento e o deploy dos satélites. Ao buscar isso no Google, você vê que o termo lançamento vem antes de deploy, isso significa que eles lançam o foguete com o satélite e rodam o deploy do satélite que deixa ele pronto para ser usado.

Por que isso é importante?

Falamos bastante sobre a definição formal de feature e deploy, mas como isso funciona na indústria de software? Uma feature é uma característica única de uma parte da aplicação. Por exemplo: uma navbar, um dashboard ou uma interação complexa da sua regra de negócio. O deploy é tornar um recurso disponível para uso, e não usá-lo de fato. Em vias práticas, é colocar um código em produção, como uma feature, mas não necessariamente deixar o usuário usá-la.

Pela definição e significado das palavras temos duas conclusões:

• Primeiro, feature é necessariamente visual, no contexto de software usamos erroneamente a tradução literal para funcionalidade. Fazer essa tradução pode fazer sentido para muitos casos, mas em alguns pode levar o seu time a esboçar um esforço equivocado pelo mau uso da palavra;
• Segundo, deploy e lançamento soam como a mesma coisa, mas são explicitamente disjuntos. Isso nos concluir que o deploy deve ser feito o tempo todo, enquanto o lançamento deve ser programado e coordenado, seja com o seu time, com a operação da sua empresa ou com os seus usuários.

Empodere times e usuários

Empoderar é uma palavra muito clichê. Já que é para gastar o clichê porque não falarmos da curva de adoção? Ela pode ser muito clichê, sobretudo porque ela é mal usada, mas ela serve perfeitamente para destacar uma estratégia de mitigação de risco com lançamentos incrementais (rollout).

Curva de adoção dos usuários

Vamos ao cenário feliz. Você desenvolve a feature, faz o deploy (que não está acoplado do lançamento) e deixa essa funcionalidade disponível para toda a base, zero bugs em produção. Lindo não é!? Veja bem… Se for uma feature nova a tendência é que seus usuários gostem dela, mas isso não é bem verdade, as pessoas mais conservadoras tendem a resistir o uso de novas funcionalidades e tendem a ficarem perdidas com elas. Estamos falando do caminho feliz. E se esse lançamento incluir uma série de bugs? Até mesmo os entusiastas vão detratar da sua aplicação. Mais longe ainda, e se você modificou uma feature que os usuários já usam e inseriu um bug, qual o nível de confiança dos seus usuários com a sua aplicação?

Ao lançar uma feature, ou uma modificação de uma feature, devemos nos atentar ao fato de que existe um impacto. Explico muito sobre o impacto do que foi desenvolvido no artigo sobre revisão de código. O jeito mais clássico para mitigar riscos é restringindo o impacto.

Então, assumindo um cenário ruim onde você inseriu um bug (digo ruim porque sempre dá para piorar, então não vamos abordar o pior caso) que tal mitigarmos o risco de acordo com a curva de adoção em estratégias de rollout. Se você tiver esse grupo já segmentado, sobretudo com beta-testers, fica muito mais fácil. Se não tiver esse grupo segmentado, opte pela estratégia de rollout, primeiro libere para um grupo específico de usuários, depois para 10% da base, depois 20%, 40% e por fim para 100% dos usuários. Estratégias de rollout permite times de engenharia se anteciparem com problemas gerando o menor impacto possível nos usuários. Voltando a premissa de que um bug foi inserido e você percebe logo no rollout de 10%, você atuará com muito mais tranquilidade na solução desse bug.

Como isso funciona feature toggle na prática? Você tem um condicional que verifica se o usuário deve ou não usar esse recurso específico.

if (FeatureToggle.getTreatment('new-feature') == 'on') {
  // executa o código que mostra a feature para o usuário
} else {
  // mantem o comportamento antigo
}

Nesse trecho de código ilustrado, essa "classe" FeatureToggle, deverá saber se o usuário deve ou não visualizar essa feature. Essa "classe" sabe se o usuário específico deve ou não visualizar essa feature a partir de uma política de rollout pré-definida. Vou explicar esse funcionamento na seção mais prática deste artigo.

Uma vez que tenho esse código implementado, posso configurar a política inicial de rollout para zero usuários e fazer o deploy numa sexta-feira 13 as 17:59.

Como fazer um lançamento mais preciso sem aumentar os riscos?

O risco de inserir um bug é iminente. Com feature toggle você mitiga esse problema fazendo lançamentos em doses ou lotes. O tamanho do seu rollout é o tamanho do risco que você está preparado para assumir. Isso é valido tanto para o desenvolvedor quanto para o dono do negócio.

Quem é o responsável pelo lançamento?

Como de costume, deploy e lançamento são a mesma coisa. Sendo a mesma coisa, fica na mão do desenvolvedor/DevOps fazer os lançamentos. O problema é que, dependendo do CI e do tempo de build, esse lançamento não é determinístico. Caso algo dê errado o rollback pode ser demorado. Mais além, precisa ser o desenvolvedor o responsável pelo lançamento?

Vamos analisar uma imagem real:

Estrutura organizacional de uma empresa não tech

Esse é o padrão de uma empresa. Várias pessoas da operação, técnicos, gerentes, diretores e um programador. É bem fácil identificador o programador nessa imagem, o que facilita atribuir mais funções e responsabilidades para o cidadão.

Mas vamos aos fatos, geralmente o programador é a pessoa do time mais distante do cliente. Não é por maldade, por falta de comprometimento do desenvolvedor ou por prepotência do mesmo, essa é a configuração tradicional das empresas. Com isso, é realmente necessário que seja o dev o responsável pelo lançamento? Que ele é o responsável pelo deploy não tem como negar, mas pelo lançamento não me parece prudente atribuir essa responsabilidade ao desenvolvedor quando se tem pessoas mais próximas do cliente e da dor que ele sente com os lançamentos do produto.

A minha conclusão é que, por uma razão de negócio, faz mais sentido a gestão do lançamento estar na mão de quem tem mais proximidade com o cliente. Cabe ainda, a essa pessoa, ter a autonomia de fazer o rollback (reversão) quando algo dá errado.

Como implementar feature toggles sem atribuir mais uma responsabilidade ao desenvolvedor?

Simples. O desenvolvedor escreve o plano de lançamento (o código) e não é responsável pelo lançamento. Fica a carga de uma pessoa não dev (designer, produteiro, business owner) fazer os lançamentos.
obs: fica mais simples fazer "demos" com feature toggles.

Feature Toggle, na prática

Como usei, e ainda uso, o Split como ferramenta de gestão de feature toggle, vou dar exemplos de como usar usando o Split. O vídeo abaixo dá uma visão geral sobre a ferramenta, mostrando como gerenciar as toggles. O Split chama uma feature toggle de split, logo, split e feature toggle são a análogos.

Tour da ferramenta Split

Front-end

O primeiro passo é configurar o ambiente dentro do Split. Isso é bem simples e nenhum passo a passo que eu faça será mais intuitivo que o da própria plataforma. Vou explicar a implementação básica, partindo da premissa que você tenha uma API key e uma feature toggle criada.

Como uma requisição é feita para o servidor do Split o client demora alguns segundos (no nosso exemplo no máximo é de 1.5s) para pegar os tratamentos ativos, isso exige que, dependendo da sua lógica, sua aplicação tenha que esperar alguns segundos para carregar o experimento. Uma vez feito isso, você já pode gerenciar o lançamento das suas features com o Split.

Como dar um pontapé (setup básico)?

Com o uso de ferramenta externa fica fácil dar um pontapé. A implementação é análoga (se não idêntica) a qualquer outra linguagem ou aplicação mobile. Todas as ferramentas de feature toggle possuem uma gama de SDKs abrangente. Tomando o Split como exemplo temos as seguintes SDKs: Android, Go, IOS, Java, JS, .NET, PHP, Python e Ruby. Lembrando que isso é mais abrangente quando vemos o ecossistema da linguagem, por exemplo, se tem uma SDK para Java então temos uma SDK para Kotlin, Scala e Clojure. Quando não houver uma SDK fica fácil integrar com a API pública.

Back-end

O uso do Split no backend é análogo ao do client-side. Usando o Node.js como exemplo, a única diferença é que não instanciamos a factory com a key do cliente, pois passamos a key do client na hora de pegar o experimento.

Um dos cuidados que é necessário ter na hora de integrar o backend com ferramentas de feature toggle externas é a latência de rede. Se cada requisição tiver que bater no Split para pegar o experimento, a sua aplicação pode sucumbir rapidamente, eu já caí nesse problema 😢. Para resolver essa treta o Split desenvolveu o Split Synchronizer, que é responsável por sincronizar as feature toggles para dentro da sua infraestrutura de rede e disponibiliza-las nas SDKs. A latência fica ridiculamente baixar com esse dispositivo. Essa é a arquitetura do Split Sinchronyzer.

Arquitetura do Split Synchronizer

Como instalar feature toggle em uma aplicação super escalável?

O Split garante o serviço. Nunca vi eles falharem na entrega do serviço, a página de status prova isso, então não há preocupação para aplicações front-end. Para aplicações backend temos um serviço que garante uma latência baixíssima da sua aplicação, garantindo que a sua aplicação não tenha problemas de escala com o uso de feature toggles.

Boas práticas

Parece que a feature toggle é um mar de rosas. Mas todo bom bolo de chocolate é viciante e tem efeitos colaterais. O mais comum é os times criarem cultura de colocar feature toggle em qualquer coisa. Até mesmo para debugar bugs ☠️.

Eis algumas das boas práticas para trabalhar feature toggle.

• Acompanhe o status das suas feature toggles. Se uma feature toggle está sempre ligada ela provavelmente deve ser removida;
• Log o uso da feature toggle e descrevas o porquê das mudanças no comportamento da feature toggle;
• Feature toggle é mais efetiva na mão de pessoas não técnicas, como times de produto, designers e analistas de negócio;
• Crie um controle de acesso baseado no grupo de cada feature toggle, não permitindo que outros times acessem as toggles que não lhe pertencem;
• Tenha em mente a necessidade de um botão de emergência (kill switch) e não tenha dó de usá-lo quando necessário;
• Opte por usar um sistema de feature toggle poliglota (javascript, ruby, kotlin);
• Ao criar uma feature toggle, crie uma branch que remova esse código.

Construir, usar open source ou pagar?

Construir uma ferramenta de feature toggle pode ser muito custoso e problemático. O Spotify levou mais de dois anos para construir essa ferramenta com um time dedicado nisso. Faz sentido a sua empresa se desgastar com isso?

E o mundo open source? Gosto muito da comunidade open source. Eu me beneficio bruscamente dela, mas contribuo muito pouco 😢. As ferramentas open-source ainda não são tão robustas quando as ferramentas privadas. Além disso, você ainda teria o trabalho de manter e escalar a ferramenta. Convenhamos que o maior desafio de uma empresa é escalar o seu negócio. Atribuir mais uma responsabilidade ao time de tecnologia pode atrapalhar a tração do seu negócio.

Construir, open-source ou comprar?

Como começar a usar feature flag: pagando, usando um lib open-source ou construindo a minha ferramenta do zero?

Primeira lei da economia: "não existe almoço grátis". Esse custo vai existir independente da escala da sua empresa. O importante é você perceber qual terá um custo menor para a sua empresa. Na minha visão, o importante é o time de engenharia focar no negócio e na tecnologia. Se existe uma tecnologia que atende bem, por que não usar?
A escala de uma empresa para construir um sistema de feature toggle deve ser realmente megalomaníaca. Para os que cultivam a comunidade open-source, esta pode ser uma saída interessante, lembrando que ainda haverá o custo de manter e escalar a aplicação (máquina e esforço humano).
Para todos os casos, a integração é simples e exige um baixo esforço.

Benchmarks

Existem três grandes players no mercado de feature toggle. O Split (que usei como exemplo neste artigo), o LaunchDarkly e o ConfigCat. O funcionamento dos três é muito similar. Usei o Split, pois o plano gratuito dele é muito mais abrangente, a documentação é mais robusta e arquitetura da solução é mais escalável. A plataforma promove produtos além da gestão feature toggles, como teste A/B, em contrapartida, a ferramenta tem um número bem apertado de assentos e é viciante pela praticidade.

O LaunchDarkly é mais encontrado na internet dentre os casos de uso. Isso se deve ao seu marketing agressivo. Dentre as ferramentas, independente da escala, essa é a mais cara. Possui algumas features diferenciais como ouso de websocket para comunicar os clientes de alterações nas feature toggles. Dependendo do seu negócio, essa feature (ou devo dizer funcionalidade 🤔) pode ser um diferencial, na minha opinião, pura perfumaria.

O ConfigCat tem crescido muito. A documentação tem melhorado bastante e é bem abrangente em features para softwares de pequena escala e grande escala. Acredito que esse software é feito de desenvolvedores para desenvolvedores. O design do site peca um pouco o que pode desencorajar pessoas não techs de usá-lo, sobretudo times de produto.

Como eu disse, as três plataformas são bem equivalentes em quase todos os critérios. O preço muda de acordo com a escala, como em todo software. Por isso resolvi tomar como base uma pequena comparação com os planos mais baratos/freemiums. Para empresas em escala pequena o ConfigCat e o Split dão uma briga boa.

╔══════════════╦═════════╦══════════════╦═════════════════════╗
║ Destaques    ║ Split   ║ LaunchDarkly ║ ConfigCat           ║
╠══════════════╬═════════╬══════════════╬═════════════════════╣
║ Preço        ║ Grátis  ║ $90/Mês      ║ Grátis              ║
║ SDKs         ║ ✔️       ║ ✔️            ║ ✔️                   ║
║ API Pública* ║ ✔️       ║ ✔            ║ ✔️                   ║
║ MAUs         ║ ∞       ║ 1.000        ║ ∞                   ║
║ Assentos     ║ 10      ║ 1            ║ ∞                   ║
║ Segmentação  ║ ∞       ║ ∞            ║ 4                   ║
║ Logs         ║ ∞       ║ ∞            ║ 35 dias de retenção ║
╚══════════════╩═════════╩══════════════╩═════════════════════╝
MAUs: Monthly Active Users (usuários ativos no mês)
*: as APIs públicas estão disponíveis para a gestão das feature toggles de cada plataforma, isso não é valido para todos os serviços que as plataformas disponibilizam ($$).

Para os que pretendem ir para uma linha open source, deixo um site que explica com mais profundidade feature toggles e tem uma lista curada de várias iniciativas open source: https://featureflags.io/feature-flags/

Próximos Passos

Dependendo do seu time e do seu negócio, você vai se perguntar: como fazer isso no backend? Como resolver problemas como migrations? Essa estratégia é uma, entre algumas, das formas de se fazer integração contínua como blue-green deployment e canary release. Quando falei as definições de feature eu quis realçar que feature toggles tem um apelo mais visual. Usar para outras finalidades podem fazer com que a sua aplicação ganhe uma personalidade mais “gambiarrada”.

Por fim, feature toggles e testes A/B se distinguem por um único parâmetro, a conversão. Se você usa feature toggle para desviar fluxo aleatoriamente, adicionando uma ação de conversão (e metrificando isso) você criou um teste A/B usando uma única ferramenta. Ainda não consegui aplicar teste A/B com o Split, pois o contexto que venho atuando nos últimos tempos é mais voltado a backoffice, o que não me dá uma amostragem estatisticamente significante. Compartilhe comigo se você já consegue fazer isso. 😉

Como fazer deploy às 17:59 em uma sexta-feira 13?

Primeiro, deixe a superstição de lado, o risco de deploy em uma sexta deve ser igual ao de um deploy na segunda, zero! Outra coisa, com exceção dos feriados, as sextas são todas iguais, independente se é 13 ou não. O lançamento precisa ser coordenado e, para a maioria dos casos, faz mais sentido acontecer no início da semana. Por isso, separando o deploy do lançamento, podemos rodar o deploy o tempo todo, a toda hora.

[Off Topic] Deixo a minha reflexão sobre a superstição de gatos pretos

Como um engenheiro de software ou um gerente de produto (PM), a sua missão é entregar software de qualidade no tempo. Você busca tornar o seu time mais rápido, produtivo e coordenado. Mais importante, você quer que os seus clientes amem o seu produto. Feature toggle pode te ajudar a atingir todos esses objetivos. Como? Entregas no tempo, com menos risco para um produto que os seus usuários amam.

Tem interesse em trabalhar conosco? Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa tripulação! Você pode conferir nossas vagas aqui.