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:
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.
Trabalho de implantação de fila:
O Azure Pipelines agenda o trabalho de implantação em um Agente disponível.
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.
Download de artefatos:
O agente recupera e baixa todos os artefatos especificados na versão.
Execute as tarefas de implantação:
O agente executa todas as tarefas no trabalho de implantação.
Gere logs de progresso:
O agente gera logs abrangentes para cada etapa de implantação e os envia de volta para o Azure Pipelines.
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.
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.
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.
Posteriormente, ao gerar uma nova versão, você tem a capacidade de modificar os valores dessas variáveis.
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.
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.
Artigos relacionados
Comentários
https://aka.ms/ContentUserFeedback.
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja:Submeter e ver comentários