Sinalizadores de atributo

Os sinalizadores de recursos podem ser implementados em microfront-ends para facilitar a coordenação de testes e lançamento de recursos em vários ambientes. A técnica de sinalização de recursos consiste em centralizar as decisões em uma loja baseada em booleanos e direcionar o comportamento com base nisso. Geralmente é usado para propagar silenciosamente mudanças que podem ser mantidas ocultas até um momento específico, ao mesmo tempo em que desbloqueia novas versões de novos recursos que, de outra forma, seriam bloqueados, reduzindo a velocidade da equipe.

Considere o exemplo de equipes trabalhando em um recurso de microfrontend que será lançado em uma data específica. O recurso está pronto, mas precisa ser lançado junto com uma alteração em outro microfrontend que seja lançado de forma independente. Bloquear a liberação de ambos os microfront-ends seria considerado um antipadrão e aumentaria o risco quando implantado.

Em vez disso, as equipes podem criar um sinalizador de recurso booleano em um banco de dados que ambas consomem durante o tempo de renderização (talvez por meio de uma chamada HTTP para uma API de sinalizadores de recursos compartilhada). As equipes podem até mesmo lançar a alteração em um ambiente de teste em que o valor booleano é definido True para verificar os requisitos funcionais e não funcionais de vários projetos antes de iniciar a produção.

Outro exemplo de uso do sinalizador de recurso é implementar um mecanismo para substituir o valor de um sinalizador definindo um valor específico por meio do QueryString parâmetro ou armazenando uma string de teste específica em um cookie. Os proprietários do produto podem iterar os recursos sem bloquear o lançamento de outros recursos ou corrigir erros até a data de lançamento. Na data especificada, alterar o valor do sinalizador no banco de dados torna instantaneamente a alteração visível na produção, sem a necessidade de lançamentos coordenados entre equipes. Depois que um recurso é lançado, as equipes de desenvolvimento limpam o código para remover o comportamento antigo.

Outros casos de uso incluem o lançamento de um sistema de sinalização de recursos baseado em contexto. Por exemplo, se um único site atende clientes em vários idiomas, um recurso pode estar disponível somente para visitantes de um determinado país. O sistema de sinalização de recursos pode depender do consumidor que envia o contexto do país (por exemplo, usando o cabeçalho Accept-Language HTTP), e pode haver um comportamento diferente dependendo desse contexto.

Embora os sinalizadores de recursos sejam uma ferramenta poderosa para facilitar a colaboração entre desenvolvedores e proprietários de produtos, eles dependem da diligência das pessoas para evitar uma degradação significativa da base de código. Manter os sinalizadores ativos em vários recursos pode aumentar a complexidade na solução de problemas, aumentar o tamanho do JavaScript pacote e, por fim, acumular dívidas técnicas. As atividades comuns de mitigação incluem o seguinte:

• Teste unitário de cada recurso por trás de um sinalizador para reduzir a probabilidade de bugs, o que pode introduzir ciclos de feedback mais longos nos pipelines automatizados de CI/CD que executam os testes

• Criação de ferramentas para medir o aumento do tamanho do pacote durante as alterações de código, o que pode ser mitigado durante as revisões de código

AWS oferece uma variedade de soluções para otimizar os testes A/B na borda usando as CloudFront funções da Amazon ou o Lambda @Edge. Essas abordagens ajudam a reduzir a complexidade da integração de uma solução ou do produto SaaS existente que você está usando para afirmar suas suposições. Para obter mais informações, consulte Teste A/B.