Usar anéis de implantação com versões de extensão

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Com os anéis de implantação, você pode implantar e validar gradualmente as alterações em sua extensão em produção, enquanto limita o efeito sobre seus usuários.

Não recomendamos a implantação em todos os ambientes de produção ao mesmo tempo, o que expõe todos os usuários às alterações. Uma distribuição gradual expõe os usuários às alterações ao longo do tempo, validando as alterações na produção com menos usuários.

A tabela a seguir mostra as diferenças para áreas afetadas quando você está usando anéis versus nenhum anel.

Sem anéis	Área afetada	Com anéis
Manual e propenso a erros	Compilação	Automatizado e consistente
Manual e propenso a erros	Versão	Automatizado e consistente
Horas	Tempo de construção (TTB)	Segundos
Days (dias)	Tempo de liberação (TTR)	Minutos
Chamada do usuário	Detecção de problemas	Proativo
Dias a semanas	Resolução do problema	Minutos a dias

Para obter mais informações, consulte Configurando seus pipelines de versão para implantações seguras.

Pré-requisitos

• Revise os pipelines e aprovações de CI/CD para obter documentação detalhada de pipelines e os recursos de aprovação para versões.

Atribuir tipos de usuário

Determine quais usuários são mais adequados para cada tipo de usuário. Comunique a oportunidade de fornecer feedback e os níveis de risco em cada nível, pois é fundamental para definir expectativas e garantir o sucesso. No exemplo a seguir, os usuários são divididos em três grupos em produção:

• Canários: teste voluntariamente os recursos assim que estiverem disponíveis.
• Early adopters: versões de pré-visualização voluntárias, consideradas mais refinadas do que os canary bits.
• Usuários: consumam os produtos, depois de passarem por canários e early adopters.

Mapear a topologia

Mapeie a topologia de sua extensão para o modelo de implantação anelado para limitar o impacto da alteração em seus usuários e agregar valor. Para nossas extensões de comunidade de código aberto, usamos principalmente a implantação baseada em anel para expor progressivamente uma nova versão aos canários, primeiros usuários e usuários.

No nível do aplicativo, a composição das extensões do Azure DevOps é fácil de digerir, dimensionar e implantar de forma independente.

Cada extensão executa as seguintes tarefas:

• Tem um dos mais arquivos web e script
• Interfaces com o cliente Core
• Interfaces com cliente REST e APIs REST
• Persiste o estado no cache ou no armazenamento resiliente

No nível de infraestrutura, as extensões são publicadas no Marketplace. Depois de instalar a extensão em sua organização, ela é hospedada pelo portal de serviço de DevOps do Azure, com o estado persistido no armazenamento do Azure ou no armazenamento de dados de extensão.

A topologia de extensão é perfeitamente adequada para o modelo de implantação em anel e para publicar a extensão em cada anel de implantação:

• Uma versão de desenvolvimento privado para o anel canário
• Uma versão de visualização privada para o anel de adoção inicial
• Uma versão de produção pública para o anel de usuários

Dica

Publique sua extensão como privada, para controlar a exposição a usuários convidados.

Mover alterações através de anéis de implantação

Consulte o exemplo a seguir de fluxo de movimentação de alterações por meio de anéis de implantação.

Use a extensão Tarefas de Criação das Ferramentas de Desenvolvedor do Azure DevOps para empacotar e publicar extensões no Marketplace.

1. Um desenvolvedor do projeto de extensão Widget de contagem regressiva confirma uma alteração no repositório do GitHub.
2. A confirmação aciona uma compilação de integração contínua.
3. A nova compilação aciona um gatilho de implantação contínua, que inicia automaticamente a implantação do ambiente Canaries .
4. A implantação das Canárias publica uma extensão privada para o Marketplace e a compartilha com organizações predefinidas. Apenas as Canárias são afetadas pela mudança.
5. A implantação do Canaries aciona a implantação do ambiente Early Adopter . Uma porta de aprovação pré-implantação exige que qualquer um dos usuários autorizados aprove a liberação.
6. A implantação do Early Adopter publica uma extensão privada para o mercado e a compartilha com organizações predefinidas. Tanto os Canários quanto os Early Adopter são afetados pela mudança.
7. A implantação do Early Adopter aciona a implantação do ambiente Usuários . Um portão de aprovação de pré-implantação mais rigoroso exige que todos os usuários autorizados aprovem a liberação.
8. A implantação Usuários publica uma extensão pública para o mercado. Nesta fase, todos que instalaram a extensão em sua organização são afetados pela mudança.
9. É fundamental perceber que o efeito aumenta à medida que sua mudança se move através dos anéis. Expor a alteração aos Canários e aos Early Adopters oferece duas oportunidades para validar a alteração e corrigir bugs críticos antes de liberar para produção.

Monitorar problemas

O monitoramento e os alertas podem ajudá-lo a detectar e mitigar problemas. Determine que tipo de dados é importante, por exemplo: problemas de infraestrutura, violações e uso de recursos. Concentre-se em alertas acionáveis para evitar que os usuários os ignorem e percam problemas de alta prioridade.

Dica

Comece com visualizações de alto nível de seus dados, painéis visuais que você pode assistir de longe e fazer drill-down, conforme necessário. Realize a limpeza regular de suas vistas e remova todos os ruídos. Um painel visual conta uma história melhor do que muitos e-mails de notificação, muitas vezes filtrados e esquecidos pelas regras de e-mail.

Use a Integridade do Projeto de Equipe e outras extensões para criar uma visão geral de seus pipelines, tempos de cliente potencial e de ciclo e reunir outras informações. No painel de exemplo, é evidente que há 34 compilações bem-sucedidas, 21 versões bem-sucedidas, 1 versão com falha e 2 versões em andamento.

Existe uma dependência de sinalizadores de recursos?

Não. Às vezes, você pode precisar de uma determinada funcionalidade para ser implantada como parte de uma versão, mas não inicialmente exposta aos usuários. Os sinalizadores de recursos oferecem controle refinado dos recursos incluídos na alteração. Por exemplo, se você não estiver totalmente confiante sobre um recurso, poderá usar sinalizadores de recurso para ocultar o recurso em um ou todos os anéis de implantação. Você pode habilitar todos os recursos no anel canários e ajustar um subconjunto para os primeiros usuários e usuários de produção, conforme mostrado na imagem a seguir.

Para obter mais informações, consulte Experimentação progressiva com sinalizadores de recursos.

Perguntas frequentes

P: Como você sabe que uma alteração pode ser implantada no próximo anel?

R: Você deve ter uma lista de verificação consistente para os usuários que aprovam uma versão.

P: Quanto tempo você espera antes de empurrar uma mudança para o próximo anel?

Não há duração fixa ou período de "resfriamento". Depende de quanto tempo leva para você concluir todas as validações de versão com êxito.

P: Como você gerencia um hotfix?

R: O modelo de implantação em anel permite que você processe um hotfix como qualquer outra alteração. Quanto mais cedo você detectar um problema, mais cedo poderá implantar um hotfix sem efeito nos anéis downstream.

P: Como você lida com variáveis que abrangem ambientes de lançamento compartilhados?

R: Consulte Variáveis de versão padrão e personalizadas.

P: Como você pode gerenciar os segredos usados pelo pipeline?

R: Para proteger chaves criptográficas e outros segredos usados por seus pipelines, consulte Cofre de Chaves do Azure.

Artigos relacionados

• Práticas de implantação segura
• Experimentação progressiva com sinalizadores de recursos
• Configure seus pipelines de lançamento para implantações seguras.