Faala Time. Estive afastado por uns dias, mas estou de volta. Bora para o falar do que interessa?
No último post definimos, de forma resumida, o que é esse tal de feature toggle (Feature Flag). Mas antes de sair codificando precisamos entender tudo o que envolve na decisão de uma estratégia como esta.
Se você não leu ainda, confira a primeira parte do artigo – parte 1.
Motivação
Já conhecemos em partes o que são feature toggles, mas entender seus conceitos básicos não deve ser suficiente para decidir utilizá-lo.
De modo geral a adoção da estratégia de Feature Toggle parece ser uma tarefa simples. Todo o código possui pontos de decisão, então aplicá-la às nossas necessidades de desenvolvimento de soluções “adaptáveis” não seria um problema.
Utilizar qualquer técnica de forma isolada pode não gerar os benefícios desejados. Nem tudo é código. Para utilizar esta estratégia espera-se, além de tudo, maturidade do time. Não estou relacionando a palavra time somente para a equipe de desenvolvimento, mas a TODOS os envolvidos no produto.
Sendo assim, para utilizar features toggles, precisamos ter um ótimo gerenciamento, trabalhar em um ambiente automatizado com integração contínua(CI), entrega contínua(CD), um bom plano de gerenciamento de branches, um bom processo alinhado com as estratégias de negócio e, claro, TESTES e mais TESTES (Cada assunto citado pode gerar N outros artigos).
Grandes poderes, grandes responsabilidades.
Tio Ben
De fato, não é apenas um if. Utilizar a estratégia de Toggles vai muito além do código e gera, sim, mais complexidade. Mas considere isso um grande benefício. O nível de maturidade da equipe e de todas as técnicas utilizadas em seu projeto irão para um outro patamar.
E qual a vantagem de utilizar?
Pense em um cenário ruim: um código foi submetido para produção e logo começaram a surgir muitas notificações de erro em nossas ferramentas de monitoramento, por parte dos usuários. Este não é um cenário incomum na vida de um programador.
Quando implementados a estratégia de toggles temos ao nosso lado o famoso “botão vermelho”.
Aconteceu algo errado em produção? Então desliga! Simples assim. Pensando em um pior cenário, poder desligar um comportamento inadequado é uma ótima respostas, além de ágil, aos problemas.
Além deste cenário existem vários outros, como lançar novas versões de forma incremental, testes A/B, publicações em horários específicos entre várias outras vantagens.
Mais do que um If e uma complexidade de utilização, os feature toggles possuem muitas vantagens, benefícios. Então implementá-lo pode ser interessante não somente para ter as possibilidades citadas acima, mas também na maturidade da equipe.
Por onde começar?
Existem vários tipos de toggles, mas podemos começar a implementar os Release Toggles:
Este tipo de toggle já viabiliza o uso da estratégia de Trunk Based, por exemplo. Podem ocorrer entregas para produção com código ainda em desenvolvimento, porém protegidos por um toggle. Conforme visualizado na imagem, os releases toggles possuem uma característica de não serem longínquos.
Existem outros tipos de toggles como boas práticas, mas que falaremos posteriormente.
A, vai uma dica: Não utilize a estratégia de feature toggles em determinados ambientes. Isso pode lhe trazer grandes problemas. Tenha em mente que esta técnica deve ser aplicada em todo o seu cenário de desenvolvimento, independente do ambiente.
Próximos passos
São muitas informações para um artigo apenas. Por isso vamos passo a passo para procurar entender não somente o que está relacionado a código e infraestrutura, mas também em relação à gestão e time.
No próximo artigo vamos entender as premissas para iniciar o desenvolvimento com Feature Toggles e iniciar um projeto prático, além de trazer alguns pontos de atenção com base em minha experiência.
Até lá!
Referência
https://martinfowler.com/articles/feature-toggles.html
https://www.slideshare.net/andrepaulovich/levando-seu-scm-outro-nvel-com-feature-flags-182492139