Pipelines de lançamento clássicos
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Os pipelines de lançamento clássicos fornecem aos desenvolvedores uma estrutura para implantar aplicativos em vários ambientes de forma eficiente e segura. Usando pipelines de lançamento clássicos, você pode automatizar processos de teste e implantação, configurar estratégias de implantação flexíveis, incorporar fluxos de trabalho de aprovação e garantir transições de aplicativos suaves em vários estágios.
Como funcionam os pipelines de lançamento
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 é disparada, o Azure Pipelines verifica se uma aprovação pré-implantação é necessária antes de implantar uma versão em um estágio. Se a aprovação for necessária, ele enviará notificações por email para os aprovadores apropriados.
Trabalhos 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 pega o trabalho de implantação. Um pipeline de lançamento pode ser configurado para selecionar dinamicamente um agente adequado durante o runtime.
Baixar artefatos
O agente recupera e baixa todos os artefatos especificados no lançamento.
Execute a tarefa de implantação:
O agente executa todas as tarefas no trabalho de implantação.
Gerar logs de progresso:
O agente gera logs abrangentes para cada etapa de implantação e os envia de volta ao Azure Pipelines.
Aprovação pós-implantação:
Após a conclusão da implantação em um estágio, o Azure Pipelines verificará se uma aprovação pós-implantação é necessária para esse estágio específico. Se nenhuma aprovação for necessária, ou com a obtenção de uma aprovação necessária, ele prossegue para iniciar a implantação para o próximo estágio.
Modelo de implantação
Os pipelines de lançamento do Azure dão suporte a uma ampla variedade de fontes de artefato, incluindo Jenkins, Azure Artifacts e Team City. O exemplo a seguir ilustra um modelo de implantação usando pipelines de lançamento do Azure:
No exemplo a seguir, o pipeline consiste em dois artefatos de compilação originados de pipelines de build separados. O aplicativo é implantado inicialmente no estágio de Desenvolvimento e, em seguida, em dois estágios de garantia de qualidade. Se a implantação for bem-sucedida em ambos os estágios de garantia de qualidade, o aplicativo será implantado no anel de produção 1 e, em seguida, no anel de produção 2. Cada anel de produção representa várias instâncias do mesmo aplicativo Web implantadas em vários locais ao redor do mundo.
Versões versus implantações
A versão é um constructo que acomoda um conjunto de artefatos com versão especificado 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 lançamento, 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 lançamento e 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 build e quaisquer outras ações especificadas para esse estágio. Iniciar uma versão começa cada implantação com base nas configurações e nas políticas definidas no pipeline de lançamento original. Pode haver várias implantações de cada versão, até mesmo para um estágio. Quando uma implantação de versão falha para 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 você deseja implantar e selecionar implantar.
O diagrama a seguir mostra a relação entre lançamento, pipelines de lançamento e implantações.
Perguntas frequentes
P: Por que minha implantação não foi acionada?
R: A criação de um pipeline de lançamento 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 determinam a ordem de execução e quando as versões são enfileiradas para implantação.
Aprovações ou portões de pré-implantação: estágios específicos podem exigir aprovações ou portões de pré-implantação, impedindo a implantação até que todas as condições definidas sejam atendidas.
P: Como posso editar variáveis no momento do lançamento?
R: Na guia Variáveis do pipeline de lançamento, marque na caixa de seleção Configurável no momento do lançamento as variáveis que você deseja modificar quando um lançamento é enfileirado.
Posteriormente, ao gerar um novo lançamento, você tem a capacidade de modificar os valores dessas variáveis.
P: Quando seria mais apropriado modificar um lançamento em vez do pipeline que o 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 lançamento.
P: Quais são os cenários em que o recurso "abandonar um lançamento" é útil?
R: Se você não planeja reutilizar o lançamento ou deseja impedir que ela seja usada, abandone o lançamento da seguinte maneira 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 fazer para gerenciar os nomes de novos lançamentos?
R: A convenção de nomenclatura padrão para pipelines de lançamento é a numeração sequencial em que os lançamentos 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 lançamento. Na guia Opções do pipeline de lançamento, navegue até a página Geral e ajuste a propriedade Formato do nome do lançamento para atender às 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 para build 20170213.2 MySampleAppBuild.
| Variável | Descrição |
|---|---|
| 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. Há suporte para qualquer combinação de M/MM/MMM/MMMM, d/dd/ddd/dddd, y/yy/yyyy/yyyy, h/hh/H/HH, m/mm, s/ss. |
| System.TeamProject | O nome do projeto ao qual este build pertence. |
| Release.ReleaseId | A ID da versão, que é exclusiva em todas as versões do projeto. |
| Release.DefinitionName | O nome do pipeline de lançamento ao qual a versão atual pertence. |
| Build.BuildNumber | O número do build contido na versão. Se uma versão tiver vários builds, será o número do build primário. |
| Build.DefinitionName | O nome do pipeline do build contido na versão. Se uma versão tiver vários builds, será o nome do pipeline do build primário. |
| Artifact.ArtifactType | O tipo da origem do artefato vinculada à versão. Por exemplo, isso pode ser Azure Pipelines ou Jenkins. |
| Build.SourceBranch | O branch da origem do artefato primário. Para o Git, será do formulário main se o branch for refs/heads/main. Por Controle de Versão do Team Foundation, isso será do branch de formulário se o caminho do servidor raiz para o workspace for $/teamproject/branch. Essa variável não está definida para Jenkins ou outras fontes de artefato. |
| Variável personalizada | O valor de uma propriedade de configuração global definida no pipeline de lançamento. Você pode atualizar o nome da versão com variáveis personalizadas usando os Comandos de log de versão |
P: Como defino o período de retenção para meus lançamentos?
R: Confira políticas de retenção para saber como configurar políticas de retenção para seus pipelines de lançamento.