Pipelines de liberação clássicos

Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019

Os pipelines de versão clássicos fornecem aos desenvolvedores uma estrutura para implantar aplicativos em vários ambientes de forma eficiente e segura. Usando pipelines de liberação clássicos, você pode automatizar processos de teste e implantação, configurar estratégias flexíveis de implantação, incorporar fluxos de trabalho de aprovação e garantir transições suaves de aplicativos em vários estágios.

Como funcionam os pipelines de liberação

Como parte de cada implantação, o Azure Pipelines executa as seguintes etapas:

  1. Aprovação pré-implantação:

    Quando uma nova solicitação de implantação é acionada, o Azure Pipelines verifica se uma aprovação de pré-implantação é necessária antes de implantar uma versão em um estágio. Se a aprovação for necessária, ele envia notificações por e-mail para os aprovadores relevantes.

  2. Trabalho de implantação de fila:

    O Azure Pipelines agenda o trabalho de implantação em um Agente disponível.

  3. Seleção do agente:

    Um agente disponível escolhe o trabalho de implantação. Um pipeline de liberação pode ser configurado para selecionar dinamicamente um agente adequado durante o tempo de execução.

  4. Download de artefatos:

    O agente recupera e baixa todos os artefatos especificados na versão.

  5. Execute as tarefas de implantação:

    O agente executa todas as tarefas no trabalho de implantação.

  6. Gere logs de progresso:

    O agente gera logs abrangentes para cada etapa de implantação e os envia de volta para o Azure Pipelines.

  7. Aprovação pós-implantação:

    Após a conclusão da implantação em um estágio, o Azure Pipelines verifica se uma aprovação pós-implantação é necessária para esse estágio específico. Se nenhuma aprovação for necessária, ou uma vez obtida uma aprovação necessária, ele prosseguirá para iniciar a implantação para a próxima etapa.

Uma captura de tela mostrando as etapas de implantação no Azure Pipelines.

Modelo de implementação

Os pipelines de versão do Azure dão suporte a uma ampla variedade de fontes de artefatos, incluindo Jenkins, Azure Artifacts e Team City. O exemplo a seguir ilustra um modelo de implantação usando pipelines de versão do Azure:

No exemplo a seguir, o pipeline consiste em dois artefatos de construção originários de pipelines de construção separados. O aplicativo é inicialmente implantado no estágio de desenvolvimento e, em seguida, em dois estágios de controle de qualidade separados. Se a implantação for bem-sucedida em ambos os estágios de QA, o aplicativo será implantado no anel Prod 1 e, em seguida, no anel Prod 2. Cada anel de produção representa várias instâncias do mesmo aplicativo Web, implantadas em diferentes locais em todo o mundo.

Uma captura de tela mostrando as etapas de implantação de um pipeline de versão.

FAQ

P: Como posso editar variáveis no momento do lançamento?

R: Na guia Variáveis do seu pipeline de liberação, marque a caixa de seleção Settable at release time para as variáveis que você deseja modificar quando uma liberação é enfileirada.

Uma captura de tela mostrando como ativar o recurso configurável no momento do lançamento.

Posteriormente, ao gerar uma nova versão, você tem a capacidade de modificar os valores dessas variáveis.

Uma captura de tela mostrando como editar variáveis no momento do lançamento.

P: Quando seria mais apropriado modificar uma versão em vez do pipeline que a define?

R: Você pode editar as aprovações, tarefas e variáveis de uma instância de versão. No entanto, essas edições só se aplicarão a essa instância. Se você quiser que suas alterações se apliquem a todas as versões futuras, edite o pipeline de versão.

P: Quais são os cenários em que o recurso "abandonar uma versão" é útil?

R: Se você não planeja reutilizar a versão, ou quer impedir que ela seja usada, você pode abandonar a liberação da seguinte forma: Pipelines (...) >>Abandonar. Você não pode abandonar uma versão quando uma implantação está em andamento, você deve cancelar a implantação primeiro.

Uma captura de tela mostrando como abandonar uma versão.

P: Como faço para gerenciar a nomeação de novas versões?

R: A convenção de nomenclatura padrão para pipelines de liberação é a numeração sequencial, onde as versões são denominadas Release-1, Release-2 e assim por diante. No entanto, você tem a flexibilidade de personalizar o esquema de nomenclatura modificando a máscara de formato de nome de versão. Na guia Opções do pipeline de versão, navegue até a página Geral e ajuste a propriedade Formato do nome da versão de acordo com suas preferências.

Ao especificar a máscara de formato, você pode usar as seguintes variáveis predefinidas. Exemplo: O seguinte formato de nome de versão: Release $(Rev:rrr) for build $(Build.BuildNumber) $(Build.DefinitionName) criará a seguinte versão: Release 002 for build 20170213.2 MySampleAppBuild.

Variável Description
Rev: rr Um número incrementado automaticamente com pelo menos o número especificado de dígitos.
Data / Data: MMddyy A data atual, com o formato padrão MMddyy. Todas as combinações de M/MM/MMM/MMMM, d/dd/ddd/dddd, y/aaa/aaaa/aaaa, h/hh/H/HH, m/mm, s/ss são suportadas.
System.TeamProject O nome do projeto ao qual esta construção pertence.
Release.ReleaseId O ID da versão, que é exclusivo em todas as versões do projeto.
Release.DefinitionName O nome do pipeline de liberação ao qual a versão atual pertence.
Build.BuildNumber O número da compilação contida na versão. Se uma versão tiver várias compilações, é o número da compilação principal.
Build.DefinitionName O nome do pipeline da compilação contida na versão. Se uma versão tiver várias compilações, é o nome do pipeline da compilação primária.
Artifact.ArtifactType O tipo de fonte do artefato vinculado à versão. Por exemplo, isso pode ser Azure Pipelines ou Jenkins.
Build.SourceBranch O ramo da fonte primária do artefato. Para o Git, esta é a forma principal se o ramo for refs/heads/main. Para o Controle de Versão do Team Foundation, isso é da ramificação do formulário se o caminho do servidor raiz para o espaço de trabalho for $/teamproject/branch. Esta variável não está definida para Jenkins ou outras fontes de artefatos.
Variável personalizada O valor de uma propriedade de configuração global definida no pipeline de versão. Você pode atualizar o nome da versão com variáveis personalizadas usando os comandos Release logging

P: Como posso definir o período de retenção para as minhas libertações?

R: Consulte as políticas de retenção para saber como configurar políticas de retenção para seus pipelines de lançamento.