Fundo
Se você leu meu blog anterior sobre sinalizadores de recursos , sabe que eles são uma ferramenta poderosa.
No entanto, adicionar sinalizadores de recursos torna seu código mais difícil de ler e manter à medida que as matrizes de teste se expandem.
Este blog apresenta um processo de desenvolvimento/ciclo de vida de feature flags direto para mitigar esses desafios complexos. Este processo o orienta por todos os estágios de feature flags: planejamento e design, teste, produção, monitoramento e estágio de aposentadoria.
Embora os exemplos de código sejam escritos em Python, os conceitos que descrevo são os mesmos para qualquer SDK de sinalizador de recurso escrito em qualquer linguagem de programação que você escolher.
Para um projeto Python completo e funcional que seja implantado no AWS AppConfig e use sinalizadores de recursos em tempo de execução, clique aqui .
Propriedade
Acredito que a equipe de desenvolvimento é responsável pelo processo de sinalização de recursos do início ao fim.
A equipe e seu líder são obrigados a implementar o sinalizador de recurso e gerenciá-lo durante todo o seu ciclo de vida.
A equipe de desenvolvimento é a fonte da verdade do design, pois tem o melhor entendimento dos efeitos colaterais do sinalizador de recurso, implementação, pontos de falha e como superá-los.
CI/CD Loop infinito
Planejar, codificar e construir
Depois que um novo recurso planejado for considerado significativo o suficiente ou arriscado, você deve considerar habilitá-lo por meio de um sinalizador de recurso.
A implementação mais direta é um único ponto de execução com uma única declaração ' if-else '. Considere o seguinte exemplo de pseudocódigo:
Como 'get_my_feature_flag' é implementado?
Apresentei uma implementação para buscar e avaliar sinalizadores de recursos na minha série de blogs AWS Lambda Cookbook . Ela é baseada no AWS AppConfig e no AWS Lambda Powertools .
Esse blog também descreve como separar o sinalizador de recurso do pipeline de função do AWS Lambda, tornando-o verdadeiramente dinâmico. Um sinalizador de recurso dinâmico permite que você altere rapidamente o comportamento da função do AWS Lambda sem reimplantar a função. Leia mais sobre configuração estática vs. dinâmica aqui .
Esteja ciente de que qualquer solução de terceiros também funciona. Escolha uma solução que se ajuste melhor às suas necessidades.
Teste
A maioria das pessoas concentra seus testes no caso de uso óbvio: habilitar o recurso e testar a nova lógica que o cerca: verificar se a lógica de negócios é tratada corretamente e se os efeitos colaterais são os esperados. Eles também garantirão que a cobertura do código permaneça a mais alta possível se forem minuciosos.
No entanto, também é essencial verificar se a lógica do recurso NÃO é executada quando o valor do sinalizador do recurso é False . Isso pode parecer óbvio , mas executar a lógica de um recurso quando seu sinalizador está definido como False pode ter resultados horríveis. Pode ser causado por bugs no código ou casos extremos.
Teste de integração/unidade com simulações
Os testes neste exemplo são executados localmente e não na AWS, pois usam simulações do Pytest .
No exemplo a seguir, ' my_handler ' é testado quando ' my_feature ' está habilitado.
O manipulador é chamado com um evento gerado e uma função ' get_my_feature_flag ' simulada. Embora o teste seja executado localmente com simulações do Pytest, o manipulador ainda pode chamar serviços reais e não apenas simulações. Defina simulações e valores de retorno que simulem os casos extremos do teste.
As linhas 8 a 9 habilitam o recurso.
A linha 11 aciona o manipulador Lambda com um evento simulado.
Nas linhas 12 e 13, o teste verifica se a saída do manipulador e os efeitos colaterais do recurso (quando habilitado) são os esperados.
E agora, o teste é executado novamente, mas o recurso é simulado como desabilitado:
O recurso está desabilitado nas linhas 8–9.
O teste verifica na linha 14 se o ponto de entrada do manipulador de sinalizadores de recurso não é chamado por engano.
O recurso está de fato desabilitado, pois possui apenas um ÚNICO ponto de execução.
Testes E2E
Como regra geral, os testes E2E não devem ser usados para testar a lógica de um único sinalizador de recurso.
Os testes simulados acima já testaram a lógica do sinalizador de recurso.
Os testes E2E podem simular apenas os fluxos "felizes" de todo o serviço, pois é desafiador criar falhas em serviços AWS Serverless onde você não tem controle total da infraestrutura. Por esse motivo, casos extremos e falhas simuladas são testados antes do estágio E2E nos estágios de testes de unidade e integração como testes extras para os exemplos de testes acima.
Acredito que quando um sinalizador de recurso é ' desabilitado ', todos os testes E2E devem passar e servir como uma linha de base de ' teste de sanidade' . Eles também verificam se o SDK de sinalizadores de recurso funciona conforme o esperado e se ele avalia o valor do sinalizador de recurso corretamente.
No entanto, uma vez que o sinalizador de recurso é habilitado no ambiente ' dev ', alguns testes E2E podem falhar. Essa falha sugere que os testes simulados perderam um caso de uso/caso de ponta.
Corrija os testes simulados adequadamente e continue para a próxima etapa: liberar e implantar.
Liberar e implantar
Supondo que você não implante diretamente na produção, seria sensato primeiro implantar o sinalizador de recurso como ' desabilitado ' em todos os ambientes que não sejam ' dev '.
Quando estiver pronto e puder testar e depurar, libere o sinalizador de recurso em pelo menos um ambiente que simule um ambiente de produção real: ' staging '.
Isso pode fazer com que os testes E2E falhem se seus testes simulados perderam alguns casos extremos. Nesse caso, adicione os testes ausentes e continue o lançamento.
Liberar para produção
Há inúmeras estratégias de implantação. Escolha a que se encaixa na sua necessidade.
Estratégias comuns de implantação incluem ' tudo de uma vez ', implantação ' canário ' e ' lançamento escuro '.
Leia mais sobre estratégias de implantação para AWS AppConfig aqui .
Leia mais sobre o Dark Launching no blog de Martin Fowler.
Monitorar e operar
Depois que o recurso for ao ar, não há como voltar atrás. Se houver um problema, você precisa agir rápido:
Desabilite o sinalizador de recurso o mais rápido possível.
Atualize os testes e adicione casos de uso ausentes.
Implantar e relançar.
Realize uma reunião retrospectiva — tente identificar outros casos de uso negligenciados.
Mas como sei se há um problema?
O monitoramento depende muito dos sinalizadores de recursos escolhidos. Eu uso o AWS AppConfig.
O AWS AppConfig tem verificações de integridade automáticas que podem monitorar qualquer alerta do CloudWatch.
Também é possível definir uma reversão automática de configuração se um alerta do AWS CloudWatch for acionado. Leia mais sobre isso aqui .
Outras soluções, como o AWS CloudWatch Evidently, fornecem gráficos e insights sobre o sinalizador de implantação habilitado.
Lembre-se de que definir alertas do AWS CloudWatch que monitoram a integridade e o status do seu serviço é considerado uma prática recomendada, independentemente do uso dos sinalizadores de recursos.
Planeje se aposentar
Os sinalizadores de recursos são poderosos e viciantes . No entanto, quanto mais você adiciona, a complexidade do seu código e a sobrecarga de testes aumentam.
No entanto, você não está preso para sempre a esses sinalizadores de recursos.
Não há problema e é recomendável dar o "machado" neles quando eles atingirem a maturidade e a estabilidade.
O princípio fundamental aqui é a visibilidade . Certifique-se de que você pode visualizar TODOS os seus sinalizadores de recursos em TODAS as suas contas da AWS em uma única visualização. Você precisa entender o estado completo dos sinalizadores de recursos em todas as contas da AWS rapidamente. Se a ferramenta de sua escolha não fornecer tal maneira, crie você mesmo. Pode ser um painel simples ou uma IU simples.
A equipe de desenvolvimento deve agendar uma reunião de uma hora por mês para revisar o estado atual dos sinalizadores de recursos e decidir quais recursos podem ser descontinuados.
Aqui estão minhas regras básicas para selecionar um candidato adequado para aposentadoria:
O recurso foi implantado para 100% dos clientes por 'X' semanas. Use o bom senso para definir 'X.'
O recurso está estável há 'X' semanas — sem problemas/bugs conhecidos.
O feedback dos clientes é positivo e não há problemas em aberto.
Não se espera que o recurso passe por nenhuma refatoração/adição.
Sua equipe de produto não o utiliza ou acredita que ele seja mais necessário.
Obrigado a Roy Ben Yosef , Alon Sadovski , Alexy Grabov e Mauro R.
Comments