Pipelines de liberação clássicos
Azure DevOps Services | 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.
Lançamentos vs implantações
Uma versão é uma construção que contém um conjunto versionado de artefatos especificados em um pipeline de CI/CD. Ele inclui um instantâneo de todas as informações necessárias para executar todas as tarefas e ações no pipeline de versão, como estágios, tarefas, políticas, como gatilhos e aprovadores, e opções de implantação. Pode haver várias versões de um pipeline de versão, e as informações sobre cada uma delas são armazenadas e exibidas no Azure Pipelines para o período de retenção especificado.
Uma implantação é a ação de executar as tarefas para um estágio, que pode incluir a execução de testes automatizados, a implantação de artefatos de compilação e quaisquer outras ações especificadas para esse estágio. Iniciar uma versão inicia cada implantação com base nas configurações e políticas definidas no pipeline de versão original. Pode haver várias implantações de cada versão, mesmo para um estágio. Quando uma implantação de uma versão falha em um estágio, você pode reimplantar a mesma versão nesse estágio. Para reimplantar uma versão, basta navegar até a versão que deseja implantar e selecionar implantar.
O diagrama a seguir mostra a relação entre release, pipelines de liberação e implantações.
FAQ
P: Por que minha implantação não foi acionada?
R: A criação de um pipeline de liberação não inicia automaticamente uma implantação. Aqui estão algumas razões pelas quais isso pode acontecer:
Gatilhos de implantação: gatilhos de implantação definidos podem fazer com que a implantação seja pausada. Isso pode ocorrer com gatilhos agendados ou quando há um atraso até que a implantação em outro estágio seja concluída.
Políticas de enfileiramento: essas políticas ditam a ordem de execução e quando as liberações são enfileiradas para implantação.
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.