DEV Community

loading...

App Configuration: um mundo entre configurações de ambiente e feature flags

juscelior profile image Pode me chamar de Juscélio Reis Originally published at Medium on ・6 min read

Feature Flags, ou Feature toggles, é uma técnica de desenvolvimento de software em que consiste na modificação de comportamento do sistema sem alterar o código fonte da mesma.

Qual o preço para usar essa maravilhosa técnica?

Simples, aumento na complexidade do desenvolvimento da aplicação.

Mas calma, podemos usar esse recurso maneira inteligente com o auxílio de ferramenta especializada, e essa ferramenta é o tema desse artigo Azure App Configuration.

App Configuration prover uma forma simples para que os desenvolvedores possam armazenar as configurações de suas aplicações, gerenciar as funcionalidades de sua aplicação. Sabe qual a parte mais incrível dessa ferramenta? É compatível com qualquer linguagem, existe bibliotecas para o .net core, .Net (Fullframework), Azure Function, Java Spring e outras através da api Rest.

Creio que para os desenvolvedores que não cansam de estudar, já ouviu falar em microserviço, e quem foi além nesse conteúdo deve ter em algum momento da vida esbarrado no termo Twelve-Factor App. Bom para quem não sabe o que é, segue uma breve descrição e qual a sua relação com o tema desse artigo:

Twelve-Factor App (aplicação doze-fatores) é uma metodologia para construir software como serviço. Indo mais além, para utilizar essa metodologia é necessário que a aplicação possua algumas características e sendo bem literal segue eles:

  • Utilizar de formatos declarativos para automatizar a configuração inicial, minimizar tempo e custo para novos desenvolvedores participarem do projeto;
  • Ter um contrato claro com o sistema operacional que o suporta, oferecendo portabilidade máxima entre ambientes que o executem;
  • São adequados para implantação em modernas plataformas em nuvem , evitando a necessidade por servidores e administração do sistema;
  • Minimizam a divergência entre desenvolvimento e produção, permitindo a implantação contínua para máxima agilidade;
  • E podem escalar sem significativas mudanças em ferramentas, arquiteturas, ou práticas de desenvolvimento.

Bom, não sou eu quem inventou essas características, é sério! Está escrito assim no site da metodologia. E como o nome da metodologia sugere existem 12 fatores para serem cuidadosamente elaborada nas suas aplicações. Somente se quiser ter um software como serviço, é claro 😜!

🗣 Até agora o autor desse artigo esta me fazendo de trouxa, pois fala, fala e não tem nada de App Configuration.

  • Leitor revoltado 😡

Sim, vou chegar lá! Só mais um pouco, preciso introduzir esse tema para. E somente aí, consigo explicar o real potencial do App Configuration e qual problema ela chegou para resolver! Vamos olhar os 12 Fatores.

Os Doze Fatores

I. Base de Código

Uma base de código com rastreamento utilizando controle de revisão, muitos deploys

II. Dependências

Declare e isole as dependências

III. Configurações 👈👈👈👈👈👈

Armazene as configurações no ambiente

IV. Serviços de Apoio

Trate os serviços de apoio, como recursos ligados

V. Construa, lance, execute 👈

Separe estritamente os builds e execute em estágios

VI. Processos

Execute a aplicação como um ou mais processos que não armazenam estado

VII. Vínculo de porta

Exporte serviços por ligação de porta

VIII. Concorrência

Dimensione por um modelo de processo

IX. Descartabilidade 👈

Maximizar a robustez com inicialização e desligamento rápido

X. Dev/prod semelhantes 👈

Mantenha o desenvolvimento, teste, produção o mais semelhante possível

XI. Logs

Trate logs como fluxo de eventos

XII. Processos de Admin

Executar tarefas de administração/gerenciamento como processos pontuais

Indiquei quais dos fatores esse serviço ajuda!!!! Se não concorda, comenta ai! A configuração de uma aplicação é algo bem comum e rotineiro no desenvolvimento, saber onde guardar o usuário e senha do banco de dados, configuração do servidor SMTP para envio de e-mail, ou até mesmo configuração do ClientId e ClientSecret dessa aplicação. Com isso, podemos dizer que existem de 2 a 3 ambientes com configurações distintas: Configuração de desenvolvimento, configuração de homologação e configuração de produção.

Existem várias formas de fazer isso, desde chapando essa configuração no código 🤦‍♀️🤦‍♂, criando 3 arquivos um para cada ambiente ou usando um serviço que centralize essas configurações, mas sendo remoto e com controle de acesso 👮‍♀️ 👮‍♂️! As duas primeiras tem o problema de versionar essas configurações em alguma ferramenta de controle de versão, podendo até mesmo informando certas credencias para pessoas que você não queria. A terceira forma, se você contou, e a última é o próprio App Configuration!!! 👇

Tenho uma configuração para cada ambiente, e na minha aplicação tem apenas uma referência para esse serviço! Podemos chamar essa referência de ConnectionString, um modo de somente leitura! Vejam um exemplo de configuração, outra relação bem interessante com a metodologia Twelve-Factor App é que eu consigo alterar uma determinada configuração e que essa alteração será refletida na aplicação.

🗣 Sem precisar reiniciar a aplicação?

  • Leitor curioso 🤓

Exatamente meu caro, não é necessário reiniciar sua aplicação para mudar valores como usuário e senha do banco de dados (quem nunca precisou fazer isso). Alterar a URL de um serviço. Posso até ter um serviço de configuração centralizado para várias aplicações, exemplo: Manter a URL do sistema de autenticação centralizada, evitando ter que alterar dezenas de serviço. Afinal, API em microserviço tende aos gremlins.

Cada bola verde é uma API

🗣 E qual a relação do App Configuration com o fator V. Construa, lance, execute? Não consigo ver nenhuma ligação.

  • Leitor revoltado 😡, ele continua lendo o artigo

Então, além de gerenciar as configurações existe outra funcionalidade bem interessante Feature Manager (em inglês pra ser chique 💁‍♀️ 💁‍♂️), consigo implementar uma forma de liberar novas versões do meu código para meus usuários/clientes apenas habilitando ou desabilitando um botão.

👈👈👈👈

Dessa forma posso implementar uma lógica, muito bem elaborada no meu software para caso eu habilite a feature beta, chama a parte X do meu software e caso essa feature está desligada chamo a parte Y do meu software.

De acordo com os meus cálculos1, quando a feature beta esta ligada o serviço GetAsync retorna a flag = Beta. E se a feature estiver desligada o retorno é a flag Não Beta.

🗣 Olhando as ilustrações vi que esta utilizando Microsoft.Percentage, pra que serve isso?

  • Leitor curioso 🤓

Boa!!!! Gostei de você caro leitor! Então, o Azure App Configuration consegue ter filtros, alguns já prontos como é o caso do Microsoft.Percentage. Esses filtros podem interferir na execução do seu código! Esse em especifico faz com que X% das minhas requisições executem o código com a feature beta habilitada e outros Y% executem sem a feature beta habilitada. E isso é ótimo!!!!

Podemos liberar nosso código para 10% dos nossos usuários, avaliar os erros e ir aumentando a porcentagem, limitado a 100% das requisições.

Vou compartilhar aqui o projeto onde eu configurei o Azure App Configuration, podemos conversar sobre. Olhem lá, podem copiar ou até mesmo criticar. 😝👻

https://github.com/juscelior/multitenant-core

🤑 E por hoje é isso galera!!! Não esqueçam de curtir (caso tenham gostado do artigo), clica em seguir para fortalecer a comunidade. Comente com o que achou. E não esqueça de compartilhar com seus coleguinhas do trabalho, bar, whatsapp, grupo da família…. 🤭

Podem ver outros artigos que escrevi aqui -> 🤞 https://medium.com/@juscelioreis 🤞

🤓😵 Referência desse artigo:

The Twelve-Factor App

Azure App Configuration best practices

Feature management overview

Azure App Configuration documentation


Discussion (0)

Forem Open with the Forem app