App Configuration: um mundo entre configurações de ambiente e feature flags
Tags: devops, featureflags, twelvefactor, featuretoggles
Published: 2020-07-13 21:40:22

---
title: App Configuration: um mundo entre configurações de ambiente e feature flags
published: true
date: 2020-04-23 01:28:38 UTC
tags: devops,featureflags,twelvefactor,featuretoggles
canonical_url: https://medium.com/@juscelioreis/app-configuration-um-mundo-entre-configura%C3%A7%C3%B5es-de-ambiente-e-feature-flags-41c4a30adce8
---

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](https://docs.microsoft.com/en-us/azure/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](https://docs.microsoft.com/en-us/azure/azure-app-configuration/quickstart-aspnet-core-app), [.Net (Fullframework)](https://docs.microsoft.com/en-us/azure/azure-app-configuration/quickstart-dotnet-app), [Azure Function](https://docs.microsoft.com/en-us/azure/azure-app-configuration/quickstart-azure-function-csharp), [Java Spring](https://docs.microsoft.com/en-us/azure/azure-app-configuration/quickstart-java-spring-app) e outras através da [api Rest](https://github.com/Azure/AppConfiguration#rest-api-reference).

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](https://12factor.net/pt_br/). 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!!! 👇

![](https://cdn-images-1.medium.com/max/1024/1*4YgLquiqCmasVP-jR646Jw.png)

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.

![](https://cdn-images-1.medium.com/max/947/1*hIspo56L94AJgLGgTVGPMA.png)

> 🗣 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.

![](https://cdn-images-1.medium.com/max/1024/1*O87SaUe7WfeanJa75xTa9g.png)<figcaption>Cada bola verde é uma API</figcaption>

> 🗣 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

![](https://cdn-images-1.medium.com/max/1024/1*BhofpzXvyplyxEVtKzmAyg.png)

![](https://cdn-images-1.medium.com/max/1024/1*jf5nkBvZu6IGdhfG6ZzJFg.png)

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.

![](https://cdn-images-1.medium.com/max/774/1*b0Fayzp38ODBil4btfbWYg.png)<figcaption>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.</figcaption>

> 🗣 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](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](https://medium.com/@juscelioreis) 🤞

🤓😵 Referência desse artigo:

[The Twelve-Factor App](https://12factor.net/pt_br/)  
[Azure App Configuration best practices](https://docs.microsoft.com/en-us/azure/azure-app-configuration/howto-best-practices)  
[Feature management overview](https://docs.microsoft.com/en-us/azure/azure-app-configuration/concept-feature-management)  
[Azure App Configuration documentation](https://docs.microsoft.com/en-us/azure/azure-app-configuration/)

---

{% user juscelior %}