Experimentação progressiva com sinalizadores de recursos

À medida que as equipes do DevOps alternam para uma metodologia do Agile que foca a entrega contínua de recursos, é cada vez maior a necessidade de controlar como eles são disponibilizados para os usuários. Os sinalizadores de recursos são uma ótima solução para limitar o acesso do usuário a novos recursos, para fins de marketing ou para testes em produção.

Desacoplamento, implantação e exposição

Com sinalizadores de recursos, uma equipe pode decidir se um conjunto de recursos específico é visível na experiência do usuário e/ou invocado na funcionalidade. Pode-se criar e implantar novos recursos como parte do processo de desenvolvimento comum sem dispor desses recursos para amplo acesso. A implantação de recursos é separada da exposição de maneira conveniente.

Os sinalizadores fornecem controle de runtime até usuários individuais

Os sinalizadores também fornecem controle granular até o usuário individual. Quando é chegado o momento de habilitar um recurso, seja para um usuário, um pequeno grupo ou todos, a equipe pode simplesmente alterar o sinalizador de recurso para aprimorá-lo sem precisar reimplantá-lo.

O escopo de um sinalizador de recurso variará com base na natureza do recurso e do público-alvo. Em alguns casos, um sinalizador de recurso habilitará automaticamente a funcionalidade para todos. Em outros casos, um recurso será habilitado para cada usuário. Se desejarem, as equipes também poderão usar sinalizadores de recursos para permitir que os usuários optem por habilitar um recurso. Não há de fato limite para a forma como os sinalizadores de recursos são implementados.

Apoie comentários antecipados e experimentação

Os sinalizadores de recursos são uma ótima maneira de dar suporte à experimentação inicial. Alguns recursos podem ter pontos em aberto desde o início, algo que pode interessar somente os adeptos no estágio inicial. A tentativa de difundir esses recursos não totalmente prontos junto a um público-alvo mais amplo pode gerar insatisfação. Mas é inestimável o benefício de coletar comentários de usuários dispostos a lidar com um recurso em andamento.

Comece logo a alternar

Às vezes, é útil ser capaz de desativar algo. Por exemplo, digamos que um novo recurso não esteja funcionando da forma esperada e haja efeitos colaterais que causam problemas em outros locais. Você pode usar sinalizadores de recurso para desativar rapidamente a nova funcionalidade para reverter para o comportamento confiável sem precisar reimplantar. Embora os sinalizadores de recursos sejam em geral considerados em termos de recursos de interface do usuário, eles também podem ser facilmente usados para alterações na arquitetura ou infraestrutura.

Estágios padrão

A Microsoft usa um processo de distribuição padrão para ativar sinalizadores de recursos. Há dois conceitos independentes: anéis para implantações e estágios para sinalizadores de recursos. Saiba mais sobre anéis e estágios.

Os estágios tratam de divulgação ou exposição. Por exemplo, o primeiro estágio pode ser para a conta de uma equipe e as contas pessoais dos membros. A maioria dos usuários não veriam algo novo porque os sinalizadores só estão ativados para este primeiro estágio. Isso permite que uma equipe use-o e teste-o totalmente. Após a aprovação da equipe, os clientes selecionados poderão aceitá-lo por meio do segundo estágio de sinalizadores de recursos.

Aceitar

É uma boa prática permitir que os usuários optem por sinalizadores de recursos quando viável. Por exemplo, a equipe pode expor um painel de visualização associado às preferências ou configurações do usuário.

Usar sinalizadores com telemetria

Os sinalizadores de recursos fornecem uma forma de expor atualizações de maneira incremental. Mas, as equipes devem monitorar continuamente as métricas certas para avaliar a prontidão para uma exposição mais ampla. Essas métricas devem incluir o comportamento de uso e o impacto das atualizações na integridade do sistema. É importante evitar a armadilha de supor que está tudo bem somente porque parece não haver nada de errado.

Um exemplo de sinalizador de recurso

Considere o exemplo a seguir. A equipe adicionou alguns botões aqui para Cherry-pick e Reverter na interface do usuário de solicitação de pull. Isso foi implantado por meio de sinalizadores de recursos.

Definir sinalizadores de recurso

O primeiro recurso exposto foi o botão Reverter. A solução usa um arquivo XML para definir todos os sinalizadores de recurso. Há um arquivo por serviço nesse caso, o que gera um incentivo para remover sinalizadores anteriores para evitar que a seção fique longa demais. A equipe excluirá sinalizadores antigos porque existe uma motivação natural para controlar o tamanho desse arquivo.

<?xml version="1.0" encoding="utf-8"?>
<!--
  In this group we should register Azure DevOps specific features and sets their states.
-->
<ServicingStepGroup name="AzureDevOpsFeatureAvailability" … >
  <Steps>
    <!-- Feature Availability -->
    <ServicingStep name="Register features" stepPerformer="FeatureAvailability" … >
      <StepData>
        <!--specifying owner to allow implicit removal of features -->
        <Features owner="AzureDevOps">
           <!-- Begin TFVC/Git -->
           <Feature name="SourceControl.Revert" description="Source control revert features" />

Uma estrutura de servidor comum incentiva a reutilização e economias de escala em toda a equipe. O ideal é que o projeto tenha infraestrutura para que um desenvolvedor possa simplesmente definir um sinalizador em um repositório central e ter o restante da infraestrutura tratada para eles.

Verificar sinalizadores de recursos em runtime

O sinalizador de recursos usado aqui é denominado SourceControl.Revert. Aqui está o TypeScript real dessa página que ilustra a chamada para uma verificação de disponibilidade de recursos.

private addRevertButton(): void {
 if (FeatureAvailability.isFeatureEnabled(Flags.SourceControlRevert)) {
     this._calloutButtons.unshift(
         <button onClick={ () => Dialogs.revertPullRequest(
             this.props.repositoryContext,
             this.props.pullRequest.pullRequestContract(),
             this.props.pullRequest.branchStatusContract().sourceBranchStatus,
             this.props.pullRequest.branchStatusContract().targetBranchStatus)
         }
         >
             {VCResources.PullRequest_Revert_Button}
         </button>
        );
     }
}

O exemplo acima ilustra o uso no TypeScript, mas ele pode ser facilmente acessado com o C#. O código verifica se o recurso está habilitado e, em caso positivo, renderiza um botão para fornecer a funcionalidade. Se o sinalizador não estiver habilitado, o botão será ignorado.

Controlar um sinalizador de recursos

Uma boa plataforma do sinalizador de recursos fornecerá várias formas de gerenciar se certo sinalizador for definido. Em geral, há cenários de uso para o sinalizador a ser controlado via PowerShell e interface da Web. Para o PowerShell, só precisam ser expostas as maneiras de obter e definir o status de um sinalizador de recursos, junto com parâmetros opcionais para itens como identificadores de conta de usuário específicos, se aplicável.

Controlar sinalizadores de recursos por meio da interface do usuário da Web

O exemplo a seguir usa a interface do usuário da Web exposta para este produto pela equipe. Observe o sinalizador de recursos para SourceControl.Revert. Há duas contas pessoais listadas aqui: hallux e buckh-westeur. O estado está definido para hallux, que fica no Centro-Norte, e é liberado para outra conta na Europa Ocidental.

A natureza do sinalizador de recursos delimitará a forma como os recursos são expostos. Em alguns casos, a exposição seguirá um modelo de anel e estágio. Em outros, os usuários podem aderir à interface do usuário de configuração ou até mesmo enviar um email à equipe para acesso.

Considerações sobre sinalizadores de recursos

É possível desativar a maioria dos sinalizadores de recursos após o lançamento de um recurso para todos. Nesse ponto, a equipe pode excluir todas as referências ao sinalizador no código e na configuração. É uma boa prática incluir uma revisão de sinalizador de recursos, como no início de cada sprint.

Também pode existir um conjunto de sinalizadores de recursos que persistem por vários motivos. Por exemplo, talvez a equipe deseje manter um sinalizador de recursos que ramifica algo de infraestrutura por um período após a total alternância do serviço de produção. No entanto, lembre-se de que esse possível caminho de código pode ser reativado no futuro durante uma limpeza explícita do sinalizador de recursos; assim, ele precisa ser testado e mantido até que a opção seja removida.

Sinalizadores de recursos e estratégia de ramificação

Os sinalizadores de recursos permitem às equipes de desenvolvimento incluir recursos incompletos no main sem afetar ninguém. Contanto que o caminho de código esteja isolado por trás de um sinalizador de recursos, costuma ser seguro criar e publicar esse código sem que os efeitos colaterais afetem o uso normal. Caso um recurso exija dependências, como ao expor um ponto de extremidade REST, as equipes deverão considerar como essas dependências podem gerar segurança ou trabalho de manutenção mesmo sem a exposição do recurso.

Sinalizadores de recursos para mitigar riscos

Às vezes, novos recursos têm o potencial de apresentar mudanças destrutivas ou prejudiciais. Por exemplo, o produto pode estar passando por uma transformação de um esquema de banco de dados amplo para um longo. Nesse cenário, o desenvolvedor deve criar uma ramificação de recurso por um período curto. Eles fazem as mudanças desestabilizadoras na ramificação e mantêm o recurso atrás de um sinalizador. Uma prática comum das equipes é mesclar as mudanças até main desde que não causem danos. Isso não seria viável sem a capacidade de manter o recurso inacabado oculto atrás de um sinalizador de recursos.

Os sinalizadores de recursos ajudam a trabalhar no principal

Se você seguir as práticas com bom senso discutidas na fase de Desenvolvimento, trabalhar em main será uma boa forma de restringir um ciclo do DevOps. Quando associado a sinalizadores de recursos, os desenvolvedores podem mesclar rapidamente recursos no upstream e enviá-los por meio de test gauntlet. O código de qualidade pode ser publicado rapidamente para testes em produção. Após alguns sprints, os desenvolvedores reconhecerão os benefícios dos sinalizadores de recursos e os usarão proativamente.

Como decidir se deseja usar um sinalizador de recursos

As equipes de recursos detêm a decisão sobre se precisam ou não de um sinalizador de recursos para certa alteração. Nem toda alteração exige um; então, cabe a um desenvolvedor decidir quando fazer uma alteração. No caso do recurso Reverter abordado antes, era importante usar um sinalizador de recursos para controlar a exposição. Permitir que as equipes tomem decisões importantes sobre a área de recursos faz parte de permitir a autonomia em uma organização do DevOps eficaz.

Criar x comprar

Embora seja possível criar sua própria infraestrutura do sinalizador de recursos, em geral, recomenda-se a adoção de uma plataforma como LaunchDarkly ou Split. É preferível investir na criação de recursos e não recriar a funcionalidade do sinalizador de recursos.

Próximas etapas

Saiba mais sobre como usar sinalizadores de recursos em um aplicativo ASP.NET Core.