Experimentação progressiva com sinalizadores de recursos

À medida que as equipes do DevOps mudam para uma metodologia Agile que se concentra na entrega contínua de recursos, a necessidade de controlar como eles ficam 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.

Desassociando a implantação e a exposição

Com sinalizadores de recursos, uma equipe pode escolher se um determinado conjunto de recursos está 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 acesso amplo. A implantação de recursos é convenientemente dissociada de sua exposição.

Os sinalizadores fornecem controle de runtime para um 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 grupo pequeno ou todos, a equipe pode simplesmente alterar o sinalizador de recurso para acessá-lo sem precisar reimplantar.

O escopo de um sinalizador de recurso variará de acordo com a 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 de acordo com o usuário. O Teams também pode usar sinalizadores de recursos para permitir que os usuários optem por habilitar um recurso, se desejarem. Não há nenhum limite para a maneira como os sinalizadores de recursos são implementados.

Suporte a comentários e experimentações iniciais

Sinalizadores de recursos são uma ótima maneira de dar suporte à experimentação antecipada. Alguns recursos podem ter bordas ásperas 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 comentários de usuários dispostos a lidar com um recurso em andamento é inestimável.

Opção de desativação rápida

Às vezes, é útil ser capaz de desativar algo. Por exemplo, suponha que um novo recurso não esteja funcionando da maneira pretendida e que haja efeitos colaterais que causam problemas em outros lugares. Você pode usar sinalizadores de recursos para desativar rapidamente a nova funcionalidade para reverter para o comportamento confiável sem precisar reimplantar. Embora os sinalizadores de recursos geralmente sejam 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.

Estágios padrão

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 camadas e estágios.

Os estágios são sobre 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 veria nada novo porque o único local em que os sinalizadores estão ativados é para este primeiro estágio. Isso permite que uma equipe use e experimente totalmente com ela. Depois que a equipe se desativar, os clientes selecionados poderão aceitar isso por meio do segundo estágio de sinalizadores de recursos.

Aceitar

É uma boa prática permitir que os usuários optem por usar sinalizadores de recursos 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 incrementalmente as atualizações. No entanto, as equipes devem monitorar continuamente as métricas certas para medir a preparaçã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 Reverter na interface do usuário da solicitação de 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 recurso. Nesse caso, há um arquivo por serviço, que cria um incentivo para remover sinalizadores antigos para impedir 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. O ideal é que o projeto tenha a infraestrutura em vigor 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 recurso usado aqui é chamado SourceControl.Revert. Aqui está o TypeScript real dessa página que ilustra a chamada para uma verificação de disponibilidade do 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 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 habilitado, 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 por meio do PowerShell e da interface da 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.

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

A natureza do sinalizador de recurso conduzirá a maneira como os recursos são expostos. Em alguns casos, a exposição seguirá um modelo de camada e estágio. Em outras pessoas, os usuários podem aceitar por meio da interface do usuário de configuração ou até mesmo enviando um email para a equipe para acesso.

Considerações sobre sinalizadores de recursos

A maioria dos sinalizadores de recursos pode ser desativada depois que um recurso é distribuído 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 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 infraestructural por um período após o serviço de produção ter sido totalmente substituído. No entanto, tenha em mente que esse possível codepath 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 main incompletos sem afetar mais ninguém. Desde que o codepath esteja isolado atrás de um sinalizador de recurso, geralmente é seguro criar e publicar esse código sem efeitos colaterais que afetam o uso normal. Mas se houver casos em que um recurso exija dependências, como ao expor um ponto de extremidade REST, as equipes deverão considerar como essas dependências podem criar trabalho de segurança ou manutenção mesmo sem que o recurso seja exposto.

Sinalizadores de recursos para reduzir o risco

Às vezes, novos recursos têm o potencial de introduzir alterações destrutivas ou disruptivas. Por exemplo, o produto pode estar passando por uma transformação de um amplo esquema de banco de dados para um longo. Nesse cenário, o desenvolvedor deve criar um branch de recursos por um pequeno período de tempo. Em seguida, eles fazem as alterações desestabilizadoras no branch e mantêm o recurso atrás de um sinalizador. Uma prática popular é que as equipes mesclam alterações assim main que não estiverem causando nenhum dano. Isso não seria viável sem a capacidade de manter o recurso inacabado oculto atrás de um sinalizador de recurso.

Sinalizadores de recursos ajudam a trabalhar no principal

Se você seguir as práticas de senso comum discutidas na fase Desenvolver , trabalhar main é uma boa maneira de apertar um ciclo de DevOps. Quando combinados com sinalizadores de recursos, os desenvolvedores podem mesclar rapidamente os recursos upstream e efetuá-los por push por meio da luva de teste. O código de qualidade pode ser publicado rapidamente para teste 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 um sinalizador de recurso deve ser usado

As equipes de recursos possuem a decisão de se precisam de um sinalizador de recurso ou não para uma determinada alteração. Nem todas as alterações exigem uma, portanto, é 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 possuam decisões importantes sobre sua área de recursos faz parte da habilitação da autonomia em uma organização de DevOps eficaz.

Compilar vs. comprar

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

Próximas etapas

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