DEV Community: João Pedro Gonçalves

Estratégias de Ativação de Features Flags no GitLab - exemplo prático em Flutter

João Pedro Gonçalves — Tue, 07 Mar 2023 19:13:14 +0000

Para que usamos Feature Flags

Podemos pensar em Feature Flag(FF) como a sinalização para uma Recurso de um sistema. Essa sinalização vai dizer se essa recurso está acessível ou não.

Tecnologias envolvidas

Apesar do caráter booleano das FFs, surgiram implementações e especificações que associam estratégias ao seu uso.

O Unleash contém a especificação que o package dart Unleash Client SDK, importado pela nossa aplicação, usa para interagir com a alternância de recursos(feature toggles).

O repositório do nosso app está no GitLab, este por sua vez usa o já citado Unleash para disponibilizar aos desenvolvedores as Feature Flags Gitlab.

Rodando a Aplicação exemplo

Neste pr do unleash multi tenant POC temos o estado de código suficiente para trabalhar disponibilidade de recursos usando userIDs.

git clone https://github.com/GeoSales-Evolution/unleash-multi-tenant-flutter-poc.git

Para usar o projeto com sucesso é preciso atribuir corretamente as variáveis de ambiente no arquivo .env como descrito neste post.

Em seguida é preciso rodar a aplicação.

flutter run

E finalmente chegar a tela que testa as Feature Flags.

Criando Feature Flag

Usaremos estratégias baseadas em userIDs. Como estamos trabalhando como GitLab é preciso ter acesso à um projeto nessa plataforma, e então acessar a tela de features flags.

Então Vamos criar uma Feature Flag clicando no botão New feature flag.

Estratégias

Vamos abordar 3 estratégias com exemplos

1/3 All users

Essa é a estratégia mais simples, pois não filtra(restringe) nenhum usuário.

Mesmo passando um usuário qualquer via Context, ou até mesmo sem passar usuário, receberemos positivo caso a flag esteja ativa.

Esse trecho está no PR 18 Unleash multi tenant POC, sendo responsável por por printar a disponibilidade do recurso no console.

print('Is feature accessible ? == ${unl.isEnabled(flagText, localContext: Context(userId: "usuarioqualquer"))}');

2/3 Usando userIDs diretamente

Podemos digitar as strings correspondentes aos usuários e associas essa estratégia à Feature Flag

Como não estamos passando o userID capivara no código Dart o resultado vai ser negativo.

Assim que passarmos o userID pelo contexto, temos resultado positivo.

print('Is feature accessible ? == ${unl.isEnabled(flagText, localContext: Context(userId: "capivara"))}');

OBS: hot reload pode não atualizar o construtor de Context causando erros nos seus testes.

3/3 Usando Listas de Usuários

Novamente no cabeçalho de Feature Flags, vamos escolher a opção "View Users List".

Depois "New user list"

Depois de criada a lista vamos adicionar usuários em "Add Users"

Lista pronta e contendo usuários podemos usá-la como estratégia para nossa FF.

Depois deselecionar a opção "edit", entramos na tela de edição de FFs, muda-se a estratégia e escolhemos a lista.

Caso o userID passado no contexto esteja contido na lista teremos um resultado positivo.

print('Is feature accessible ? == ${unl.isEnabled(flagText, localContext: Context(userId: "sabia"))}');

Demais estratégias

Existem outras estratégias usadas com Feature Flags, além da opção de adicionar várias estratégias na tela de edição - basta clicar em "Add strategy".

Conclusão

Usando GitLab, Flutter e Unleash vimos que as regras são todas definidas no nosso repositório GitLab, enquanto que passamos informações do usuário via Context no lado Dart para avaliar a disponibilidade do recurso.

Valeu !!

Atualizando aplicação Flutter para null safe - exemplo prático

João Pedro Gonçalves — Mon, 06 Mar 2023 19:58:15 +0000

Não comece errado

Antes de tudo tenho que saber que minha aplicação funciona na versão sem null safety que estou usando, isso no dará tranquilidade para resolver apenas problemas relacionados à atualização do Flutter.

Motivação

A aplicação alvo é o POC https://github.com/GeoSales-Evolution/unleash-multi-tenant-flutter-poc.

Estávamos usando o Flutter 1.22.2 para rodá-la, e agora queremos mudar para 2.5.0. O porquê dessa escolha além do uso do no null safe está relacionada com outros projetos que se interagem com o POC.

Montando o experimento

No caso montamos um fluxo na aplicação funcionando e o esperado é que após a migração para a 2.5.0 a aplicação funcione da mesma maneira.

No fluxo:
Usuário entra com Login e Tenant > é levado a tela de sonsulta de flags > digita um flag ativa > recebe a string 'flag ativa? == true' no console do terminal.
Essa flags são Feature Flags de um projeto no GitLab.

Abaixo prints do fluxo funcionando:

Subindo as dependências

O próprio Flutter sugere que atualizemos primeiro as dependências em ordem para depois atualizar as aplicações.

Como não temos nenhum subprojeto como dependência do nosso app vamos direto ao seu pubspec.yaml, observamos as versões dos pacotes(packages) usados e procuramos no https://pub.dev/ quais versões estão disponíveis com o nosso Flutter e Dart SDK almejados.

Por exemplo: path_provider: está na versão ^1.6.28 e podemos observar na sua página de versões path_provider que uma versão que tem null safety e atende no Dart SDK 14(Flutter 2.5.0) pode ser a 2.0.0.

Além disso, vamos atualizar a versão do Flutter e do Dart SDK no no pubspec.yaml, no nosso caso 2.5.0 e 2.14.0 respectivamente.

Dart pub upgrade

Depois decididas todas as mudanças de versões das dependências usamos uma ferramente altomatizado do dart para resolver as dependências:

dart pub upgrade

Se houver alguma incompatibilidade entre as dependências o Dart vai avisar.

dart pub get funciona também, porém prefiro upgrade por ser mais verboso.

dart migrate

dart migrate

na raiz do projeto vai fornce um relatório de problemas a serem corrigidos.

Nós esperamos dois tipos de erros: adequação ao null safety e quebra de APIs(causadas por mudanças nas APIs das dependências depois de atualizações).

Concertamos os problemas com null safety e adaptamos o código para as novas APIs das dependências. Conforme o tamanho do seu projeto esse vai ser o passo mais demorado.

Então rodamos dart migrate novamente e esperamos ver:

Rodar aplicação atualizada

flutter run

deve funcionar normalmente depois das alterações e mostrar uma mensagem:

💪 Running with sound null safety 💪

Nos resta testar a aplicação. Nesse caso estou considerando o fluxo do experimento que definimos anteriormente, e ele funcionou sem falhas conforme a captura abaixo:

O experimento não encontrou evidências de que a aplicação contém defeito(quem sabe a discussão sobre como usar experimento em outro post), logo abrimos pull request.

Valeu !

Atualizando aplicação Flutter para null safe - exemplo prático

João Pedro Gonçalves — Thu, 02 Mar 2023 01:25:58 +0000

Não comece errado

Antes de tudo tenho que saber que minha aplicação funciona na versão sem null safety usada, isso nos dará tranquilidade para resolver apenas problemas relacionados à atualização do Flutter.

Motivação

A aplicação exemplo é o POC https://github.com/GeoSales-Evolution/unleash-multi-tenant-flutter-poc.

Estávamos usando o Flutter 1.22.2 para rodá-la, e agora queremos mudar para 2.5.0. O porquê dessa escolha além do uso do null safety está relacionada com outros projetos que interagem com o POC.

Montando o experimento

Montamos um fluxo na aplicação funcionando, esperando que após a migração para a 2.5.0 a aplicação funcione da mesma maneira.

No fluxo:
Usuário entra com Login e Tenant > é levado a tela de consulta de flags > digita um flag ativa > recebe a string 'flag ativa? == true' no console do terminal.
Essa flags são Feature Flags de um projeto no GitLab.

Abaixo prints do fluxo funcionando:

Subindo as dependências

O próprio Flutter sugere que atualizemos primeiro as dependências em ordem para depois atualizar as aplicações.

Além disso, vamos atualizar a versão do Flutter e do Dart SDK no pubspec.yaml, no nosso caso 2.5.0 e 2.14.0 respectivamente.

Dart pub upgrade

Depois decididas todas as mudanças de versões das dependências usamos uma ferramenta do dart para resolver as dependências:

dart pub upgrade

Se houver alguma incompatibilidade entre as dependências o Dart vai avisar.

dart pub get funciona também, porém prefiro upgrade por ser mais verboso.

dart migrate

dart migrate

na raiz do projeto vai fornecer um relatório de problemas a serem corrigidos.

Nós esperamos dois tipos de erros: adequação ao null safety e quebra de APIs(causadas por mudanças nas APIs das dependências depois de atualizações).

Rodar aplicação atualizada

flutter run

deve funcionar normalmente depois das alterações e mostrar uma mensagem:

💪 Running with sound null safety 💪

Nos resta testar a aplicação. Nesse caso estou considerando o fluxo do experimento que definimos anteriormente, e ele funcionou sem falhas conforme a captura abaixo:

O experimento não encontrou evidências de que a aplicação contém defeito(quem sabe a discussão sobre como usar experimentos em outro post), logo abrimos pull request.

Objetivo alcançado !!