Execuções de pipeline

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

Este artigo explica a sequência de atividades em execuções de pipeline do Azure Pipelines. Uma execução representa uma execução de um pipeline. Os pipelines de integração contínua (CI) e de entrega contínua (CD) consistem em execuções. Durante uma execução, o Azure Pipelines processa o pipeline e os agentes processam um ou mais trabalhos, etapas e tarefas.

Para cada execução, Azure Pipelines:

• Processa o pipeline.
• Solicita que um ou mais agentes executem trabalhos.
• Entrega trabalhos aos agentes e recolhe os resultados.

Para cada trabalho, um agente:

• Prepara-se para o trabalho.
• Executa cada etapa do trabalho.
• Relatórios de resultados.

Os trabalhos podem ser bem-sucedidos, falhar, ser cancelados ou não concluídos. Compreender esses resultados pode ajudá-lo a solucionar problemas.

As seções a seguir descrevem o processo de execução do pipeline em detalhes.

Processamento de pipeline

Para processar um pipeline para uma execução, o Azure Pipelines primeiro:

1. Expande modelos e avalia expressões de modelo.
2. Avalia dependências no nível do estágio para escolher o primeiro estágio a ser executado.

Para cada estágio que ele seleciona para executar, Azure Pipelines:

1. Reúne e valida todos os recursos de trabalho para autorização de execução.
2. Avalia as dependências no nível do trabalho para escolher o primeiro trabalho a ser executado.

O Azure Pipelines realiza as seguintes atividades para cada trabalho que seleciona para executar:

1. Expande YAML strategy: matrix ou strategy: parallel multiconfigurações em vários trabalhos de tempo de execução.
2. Avalia as condições para decidir se o trabalho é elegível para execução.
3. Solicita um agente para cada trabalho qualificado.

À medida que os trabalhos de tempo de execução são concluídos, o Azure Pipelines verifica se há novos trabalhos qualificados para execução. Da mesma forma, à medida que os estágios são concluídos, o Azure Pipelines verifica se há mais estágios.

Variáveis

Compreender a ordem de processamento esclarece por que você não pode usar determinadas variáveis nos parâmetros do modelo. A primeira etapa de expansão do modelo opera apenas no texto do arquivo YAML. As variáveis de tempo de execução ainda não existem durante essa etapa. Após essa etapa, os parâmetros do modelo já estão resolvidos.

Também não é possível usar variáveis para resolver nomes de conexão de serviço ou ambiente, porque o pipeline autoriza recursos antes que um estágio possa começar a ser executado. As variáveis de estágio e nível de trabalho ainda não estão disponíveis. Os grupos de variáveis são, eles próprios, um recurso sujeito a autorização, pelo que os seus dados não estão disponíveis ao verificar a autorização de recursos.

Você pode usar variáveis de nível de pipeline que estão explicitamente incluídas na definição de recurso de pipeline. Para obter mais informações, consulte Metadados de recursos de pipeline como variáveis predefinidas.

Agentes

Quando o Azure Pipelines precisa executar um trabalho, ele solicita um agente do pool. O processo funciona de forma diferente para pools de agentes hospedados pela Microsoft e auto-hospedados .

Trabalhos paralelos

Primeiro, o Azure Pipelines verifica os trabalhos paralelos da sua organização. O serviço soma todos os trabalhos em execução em todos os agentes e compara isso com o número de trabalhos paralelos concedidos ou comprados.

Se não houver slots paralelos disponíveis, o trabalho tem que esperar em um slot para liberar. Quando um slot paralelo estiver disponível, o trabalho será encaminhado para o tipo de agente apropriado.

Agentes alojados na Microsoft

Conceitualmente, o pool hospedado pela Microsoft é um pool global de máquinas, embora seja fisicamente muitos pools diferentes divididos por geografia e tipo de sistema operacional. Com base no nome do pool de editores YAML vmImage ou Classic solicitado, o Azure Pipelines seleciona um agente.

Todos os agentes no pool da Microsoft são máquinas virtuais (VMs) novas e novas que nunca executaram nenhum pipeline. Quando o trabalho é concluído, a VM do agente é descartada.

Agentes autoalojados

Quando um slot paralelo estiver disponível, o Azure Pipelines examinará o pool auto-hospedado em busca de um agente compatível. Os agentes auto-hospedados oferecem recursos, que indicam que determinado software está instalado ou as configurações configuradas. O pipeline tem demandas, que são os recursos necessários para executar o trabalho.

Se o Azure Pipelines não conseguir encontrar um agente livre cujos recursos correspondam às demandas do pipeline, o trabalho continuará aguardando. Se não houver agentes no pool cujos recursos correspondam às demandas, o trabalho falhará.

Os agentes auto-hospedados normalmente são reutilizados de execução em execução. Para agentes auto-hospedados, um trabalho de pipeline pode ter efeitos colaterais, como aquecer caches ou ter a maioria das confirmações já disponíveis no repositório local.

Preparação para o trabalho

Quando um agente aceita um trabalho, ele faz o seguinte trabalho de preparação:

1. Baixa todas as tarefas necessárias para executar o trabalho e as armazena em cache para uso futuro.
2. Cria espaço de trabalho no disco para armazenar o código-fonte, artefatos e saídas usados na execução.

Execução em etapas

O agente executa etapas sequencialmente em ordem. Antes que uma etapa possa começar, todas as etapas anteriores devem ser concluídas ou ignoradas.

As etapas são implementadas por tarefas, que podem ser Node.js, PowerShell ou outros scripts. O sistema de tarefas encaminha entradas e saídas para os scripts de suporte. As tarefas também fornecem serviços comuns, como alterar o caminho do sistema e criar novas variáveis de pipeline.

Cada etapa é executada em seu próprio processo, isolando seu ambiente das etapas anteriores. Devido a esse modelo de processo por etapa, as variáveis de ambiente não são preservadas entre as etapas. No entanto, tarefas e scripts podem usar um mecanismo chamado comandos de log para se comunicar com o agente. Quando uma tarefa ou script grava um comando de log na saída padrão, o agente executa qualquer ação solicitada pelo comando.

Você pode usar um comando de log para criar novas variáveis de pipeline. As variáveis de pipeline são convertidas automaticamente em variáveis de ambiente na próxima etapa. Um script pode definir uma nova variável myVar com um valor da myValue seguinte maneira:

echo '##vso[task.setVariable variable=myVar]myValue'

Write-Host "##vso[task.setVariable variable=myVar]myValue"

Comunicação e recolha de resultados

Cada etapa pode relatar avisos, erros e falhas. A etapa relata erros e avisos na página de resumo do pipeline marcando as tarefas como bem-sucedidas com problemas ou relata falhas marcando a tarefa como falha. Uma etapa falhará se relatar explicitamente a falha usando um ##vso comando ou terminar o script com um código de saída diferente de zero.

À medida que as etapas são executadas, o agente envia constantemente linhas de saída para o Azure Pipelines, para que você possa ver um feed ao vivo do console. No final de cada etapa, toda a saída da etapa é carregada como um arquivo de log. Você pode baixar o log assim que o pipeline terminar.

O agente também pode carregar artefatos e resultados de teste, que também estão disponíveis após a conclusão do pipeline.

Estado e condições

O agente acompanha o sucesso ou fracasso de cada etapa. À medida que as etapas são bem-sucedidas com problemas ou falham, o status do trabalho é atualizado. O trabalho reflete sempre o pior resultado de cada uma das suas etapas. Se uma etapa falhar, o trabalho também falhará.

Antes de executar uma etapa, o agente verifica a condição dessa etapa para determinar se a etapa deve ser executada. Por padrão, uma etapa só é executada quando o status do trabalho é bem-sucedido ou bem-sucedido com problemas, mas você pode definir outras condições.

Muitos trabalhos têm etapas de limpeza que precisam ser executadas não importa o que aconteça, para que possam especificar uma condição de always(). A limpeza ou outras etapas também podem ser definidas para serem executadas somente no cancelamento.

Uma etapa de limpeza bem-sucedida não pode salvar o trabalho de falhar. Os empregos nunca podem voltar ao sucesso depois de entrarem no fracasso.

Tempos limite e desligamentos

Cada trabalho tem um tempo limite. Se o trabalho não for concluído no tempo especificado, o servidor cancelará o trabalho. O servidor tenta sinalizar o agente para parar e marca o trabalho como cancelado. Do lado do agente, cancelamento significa cancelar todas as etapas restantes e carregar quaisquer resultados restantes.

Os trabalhos têm um período de carência chamado tempo limite de cancelamento para concluir qualquer trabalho de cancelamento. Você também pode marcar etapas para executar mesmo no cancelamento. Após um tempo limite de trabalho mais um tempo limite de cancelamento, se o agente não relatar que o trabalho foi interrompido, o servidor marcará o trabalho como uma falha.

As máquinas do agente podem parar de responder ao servidor se a máquina host do agente perder energia ou estiver desligada, ou se houver uma falha de rede. Para ajudar a detetar essas condições, o agente envia uma mensagem de pulsação uma vez por minuto para informar ao servidor que ele ainda está operando.

Se o servidor não receber uma pulsação por cinco minutos consecutivos, ele presumirá que o agente não está voltando. O trabalho é marcado como uma falha, informando ao usuário que ele deve tentar novamente o pipeline.

az pipelines runs list --status completed --result succeeded --top 3 --output table

Run ID    Number      Status     Result     Pipeline ID    Pipeline Name               Source Branch    Queued Time                 Reason
--------  ----------  ---------  ---------  -------------  --------------------------  ---------------  --------------------------  ------
125       20200124.1  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 18:56:10.067588  manual
123       20200123.2  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:55:56.633450  manual
122       20200123.1  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:48:05.574742  manual

az pipelines runs show --id 122 --open --output table

Run ID    Number      Status     Result     Pipeline ID    Pipeline Name               Source Branch    Queued Time                 Reason
--------  ----------  ---------  ---------  -------------  --------------------------  ---------------  --------------------------  --------
123       20200123.2  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:55:56.633450  manual

az pipelines runs tag add --run-id 123 --tags YAML --output json

[
  "YAML"
]

az pipelines runs tag list --run-id 123 --output table

Tags
------
YAML

az pipelines runs tag delete --run-id 123 --tag YAML

Conteúdos relacionados

• Principais conceitos do Azure Pipelines
• Estágios, dependências e condições
• Empregos em pipelines
• Agentes do Azure Pipelines