Experimentação progressiva com sinalizadores de recursos

À medida que as equipes de DevOps mudam para uma metodologia ágil que se concentra na entrega contínua de recursos, a necessidade de controlar como eles se tornam disponíveis para os usuários torna-se cada vez mais importante. Os sinalizadores de recursos são uma ótima solução para limitar o acesso do usuário a novos recursos, seja para fins de marketing ou para testes em produção.

Desacoplamento, implantação e exposição

Com sinalizadores de recursos, uma equipe pode escolher se um determinado conjunto de recursos é visível na experiência do usuário e/ou invocado dentro da funcionalidade. Novos recursos podem ser criados e implantados como parte do processo de desenvolvimento comum sem ter esses recursos disponíveis para amplo acesso. A implantação de recursos é convenientemente dissociada de sua exposição.

Os sinalizadores fornecem controle de tempo de execução até o usuário individual

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

O escopo de um sinalizador de recurso varia de acordo com a natureza do recurso e do público. Em alguns casos, um sinalizador de recurso habilitará automaticamente a funcionalidade para todos. Em outros casos, um recurso será habilitado usuário a usuário. As equipes também podem usar sinalizadores de recursos para permitir que os usuários optem por ativar um recurso, se assim desejarem. Na verdade, não há limite para a forma como os sinalizadores de recursos são implementados.

Apoie o feedback e a experimentação precoces

Os sinalizadores de recursos são uma ótima maneira de dar suporte à experimentação inicial. Alguns recursos podem ter arestas no início, o que pode ser interessante apenas para os primeiros adotantes. Tentar empurrar esses recursos não muito prontos para um público mais amplo pode produzir insatisfação. Mas o benefício de coletar feedback de usuários dispostos a lidar com um recurso em andamento é inestimável.

Interruptor de desligamento rápido

Às vezes, é útil poder desligar algo. Por exemplo, suponha que um novo recurso não está funcionando como pretendido e há efeitos colaterais que causam problemas em outros lugares. Você pode usar sinalizadores de recursos para desativar rapidamente a nova funcionalidade para reverter para um comportamento confiável sem precisar reimplantar. Embora os sinalizadores de recursos sejam frequentemente pensados em termos de recursos de interface do usuário, eles também podem ser facilmente usados para alterações na arquitetura ou na infraestrutura.

Fases normalizadas

A Microsoft usa um processo de distribuição padrão para ativar sinalizadores de recursos. Há dois conceitos separados: as camadas são para implantações e os estágios são para sinalizadores de recursos. Saiba mais sobre níveis e estágios.

As etapas têm tudo a ver com divulgação ou exposição. Por exemplo, a primeira etapa pode ser para a conta de uma equipe e as contas pessoais dos membros. A maioria dos usuários não veria nada de novo porque o único lugar onde as bandeiras estão ativadas é para este primeiro estágio. Isso permite que uma equipe o use e experimente plenamente. Assim que a equipe assinar, os clientes selecionados poderão optar por ela por meio do segundo estágio de sinalizadores de recursos.

Aderir

É uma boa prática permitir que os usuários optem por exibir sinalizadores quando possí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 maneira de expor atualizações de forma incremental. No entanto, 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, bem como o impacto das atualizações na integridade do sistema. É importante evitar a armadilha de assumir que está tudo bem só porque nada de ruim parece estar acontecendo.

Um exemplo de sinalizador de recurso

Considere o exemplo abaixo. A equipe adicionou alguns botões aqui para Cherry-pick e Revert na interface do usuário de solicitação pull. Eles foram implantados usando sinalizadores de recursos.

Definir sinalizadores de recursos

O primeiro recurso exposto foi o botão Reverter . A solução usa um arquivo XML para definir todos os sinalizadores de recursos. Há um arquivo por serviço neste caso, o que cria um incentivo para remover sinalizadores antigos para evitar que a seção fique muito longa. A equipe excluirá sinalizadores antigos porque há 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. Idealmente, o projeto terá infraestrutura para que um desenvolvedor possa simplesmente definir uma bandeira em uma loja central e ter o resto da infraestrutura tratada para eles.

Verificar sinalizadores de recursos em tempo de execução

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

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 acessado facilmente usando C#. O código verifica se o recurso está habilitado e, em caso afirmativo, renderiza um botão para fornecer a funcionalidade. Se o sinalizador não estiver ativado, o botão será ignorado.

Controlar um sinalizador de recurso

Uma boa plataforma de sinalizador de recursos fornecerá várias maneiras de gerenciar se um determinado sinalizador está definido. Normalmente, há cenários de uso para que o sinalizador seja controlado via PowerShell e interface Web. Para o PowerShell, tudo o que realmente precisa ser exposto são maneiras de obter e definir o status de um sinalizador de recurso, juntamente com parâmetros opcionais para coisas como identificadores de conta de usuário específicos, se aplicável.

Sinalizadores de recursos de controle 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 recurso para SourceControl.Revert. Há duas contas pessoais listadas aqui: hallux e buckh-westeur. O estado está definido para o hálux, que por acaso está no Centro-Norte, e liberado para a outra conta na Europa Ocidental.

A natureza do sinalizador de recursos orientará a maneira como os recursos são expostos. Em alguns casos, a exposição seguirá um modelo de nível e estágio. Em outros, os usuários podem optar por meio da interface do usuário de configuração ou até mesmo enviando um e-mail para a equipe para acesso.

Considerações para sinalizadores de recursos

A maioria dos sinalizadores de recursos pode ser desativada assim que um recurso for implementado para todos. Nesse ponto, a equipe pode excluir todas as referências ao sinalizador em código e configuração. É uma boa prática incluir uma revisão de sinalizador de recurso, como no início de cada sprint.

Ao mesmo tempo, pode haver um conjunto de sinalizadores de recursos que persistem por vários motivos. Por exemplo, a equipe pode querer manter um sinalizador de recurso que ramifica algo de infraestrutura por um período de tempo depois que o serviço de produção tiver mudado completamente. No entanto, tenha em mente que esse caminho de código potencial pode ser reativado no futuro durante uma limpeza explícita do sinalizador de recurso, portanto, 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 que as equipes de desenvolvimento incluam recursos incompletos sem main afetar mais ninguém. Contanto que o caminho de código esteja isolado atrás de um sinalizador de recurso, geralmente é seguro criar e publicar esse código sem efeitos colaterais que afetem o uso normal. Mas se houver casos em que um recurso exija dependências, como ao expor um ponto de extremidade REST, as equipes devem considerar como essas dependências podem criar segurança ou trabalho de manutenção, mesmo sem o recurso ser exposto.

Sinalizadores de recursos para reduzir riscos

Às vezes, novos recursos têm o potencial de introduzir mudanças destrutivas ou perturbadoras. 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 pequeno período de tempo. Eles então fazem as mudanças desestabilizadoras no ramo e mantêm o recurso atrás de uma bandeira. Uma prática popular é que as equipes mesclem as mudanças assim main que elas não estiverem causando nenhum dano. Isso não seria viável sem a capacidade de manter o recurso inacabado escondido atrás de um sinalizador de recurso.

Os sinalizadores de recursos ajudam a trabalhar em principal

Se você seguir as práticas de senso comum discutidas na fase Desenvolvimento , trabalhar é main uma boa maneira de apertar um ciclo de DevOps. Quando combinado com sinalizadores de recursos, os desenvolvedores podem mesclar recursos rapidamente upstream e empurrá-los através da manopla de teste. 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 recurso

As equipes de recursos tomam a decisão de precisar ou não de um sinalizador de recurso para uma determinada alteração. Nem todas as alterações requerem uma, por isso é uma chamada de julgamento para um desenvolvedor quando ele escolhe fazer uma determinada alteração. No caso do recurso Reverter discutido anteriormente, era importante usar um sinalizador de recurso para controlar a exposição. Permitir que as equipes tomem decisões importantes sobre sua área de recursos faz parte da habilitação da autonomia em uma organização de DevOps eficaz.

Construir vs. comprar

Embora seja possível construir sua própria infraestrutura de sinalizador de recursos, a adoção de uma plataforma como LaunchDarkly ou Split é geralmente recomendada. É preferível investir na construção de recursos em vez de reconstruir a funcionalidade do sinalizador de recursos.

Próximos passos

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