Sequência de execução de pipeline

  • Artigo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

As execuções representam uma execução de um pipeline. Durante uma execução, o pipeline é processado e os agentes processam um ou mais trabalhos. Uma execução de pipeline inclui trabalhos, etapas e tarefas. Executa pipelines de CI (integração contínua) e CD (entrega contínua).

Visão geral do pipeline

Quando você executa um pipeline, muitas coisas acontecem nos tópicos. Embora muitas vezes você não precise saber sobre eles, ocasionalmente é útil ter o quadro geral. Em um alto nível, o Azure Pipelines:

No lado do agente, para cada trabalho, um agente:

Os trabalhos podem ter êxito, falhar ou ser cancelados. Também há situações em que um trabalho pode não ser concluído. Entender como isso acontece pode ajudá-lo a solucionar problemas.

Vamos dividir cada ação uma por uma.

Processar o pipeline

Expandir modelos YAML

Para transformar um pipeline em uma execução, o Azure Pipelines passa por várias etapas nesta ordem:

  1. Primeiro, expanda modelos e avalie expressões de modelo.
  2. Então avalie as dependências no nível da fase para escolher as primeiras fases a serem executadas.
  3. Para cada fase selecionada para execução, duas coisas acontecem:
  4. Para cada trabalho selecionado para execução, expanda várias configurações (strategy: matrix ou strategy: parallel em YAML) em vários trabalhos de runtime.
  5. Para cada trabalho de runtime, avalie as condições para decidir se esse trabalho está qualificado para ser executado.
  6. Solicite um agente para cada trabalho de runtime qualificado.

À medida que os trabalhos de runtime forem concluídos, o Azure Pipelines verá se há novos trabalhos qualificados para execução. Nesse caso, as etapas 4 a 6 se repetem com os novos trabalhos. Da mesma forma, à medida que os estágios forem concluídos, as etapas 2 a 6 serão repetidas para todos os novos estágios.

Essa ordenação ajuda a responder a uma pergunta comum: por que não posso usar determinadas variáveis em meus parâmetros de modelo? A etapa 1, expansão de modelo, opera exclusivamente no texto do documento YAML. As variáveis de runtime não existem durante essa etapa. Após a etapa 1, os parâmetros de modelo já foram resolvidos e não existem mais.

Ele também responde a outro problema comum: por que não posso usar variáveis para resolve conexão de serviço/nomes de ambiente? Os recursos são autorizados antes que uma fase possa começar a executar, portanto, as variáveis no nível da fase e do trabalho não estão disponíveis. Pode-se usar as variáveis no nível de pipeline, mas somente aquelas explicitamente incluídas no pipeline. Os próprios grupos de variáveis são um recurso sujeito à autorização, portanto, os dados deles também não estarão disponíveis ao verificar a autorização do recurso.

Solicitar um agente

Sempre que o Azure Pipelines precisar executar um trabalho, ele solicitará um agente ao pool. (Os trabalhos de servidor são uma exceção, pois são executados no próprio servidor do Azure Pipelines.) Os pools de agentes hospedados pela Microsoft e auto-hospedados funcionam de maneira um pouco diferente.

Solicitações de pool de agentes hospedados pela Microsoft

Primeiro, o serviço verifica os trabalhos paralelos da sua organização. Ele soma todos os trabalhos em execução em todos os agentes hospedados pela Microsoft e os compara com o número de trabalhos paralelos comprados. Se não houver slots paralelos disponíveis, o trabalho precisará aguardar a liberação de um slot.

Depois que um slot paralelo estiver disponível, o trabalho será roteado para o tipo de agente solicitado. Conceitualmente, o pool hospedado pela Microsoft é um pool global gigante de computadores. (Na realidade, são muitos pools físicos diferentes divididos por geografia e tipo de sistema operacional.) Com base no vmImage (em YAML) ou no nome do pool (no editor clássico) solicitado, um agente é selecionado.

Seleção de pool

Todos os agentes no pool da Microsoft são novas máquinas virtuais que não executaram nenhum pipeline antes. Quando o trabalho for concluído, a VM do agente será descartada.

Solicitações do pool de agentes auto-hospedados

Semelhante ao pool hospedado pela Microsoft, o serviço primeiro verifica os trabalhos paralelos da sua organização. Ele soma todos os trabalhos em execução em todos os agentes auto-hospedados e o compara com o número de trabalhos paralelos comprados. Se não houver slots paralelos disponíveis, o trabalho precisará aguardar a liberação de um slot.

Depois que um slot paralelo estiver disponível, o pool auto-hospedado será examinado para um agente compatível. Agentes auto-hospedados oferecem funcionalidades, que são cadeias de caracteres que indicam que determinado software está instalado ou que configurações estão definidas. O pipeline tem demandas, que são os recursos necessários para executar o trabalho. Se não for possível encontrar um agente livre cujas capacidades correspondem à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 para execução. Para agentes auto-hospedados, um trabalho de pipeline pode ter efeitos colaterais, como o aquecimento de caches ou a maioria dos commits já disponíveis no repositório local.

Preparar para executar um trabalho

Depois que um agente aceita um trabalho, ele tem algum trabalho de preparação a ser feito. O agente baixa (e armazena em cache para a próxima vez) todas as tarefas necessárias para executar o trabalho. Ele cria espaço de trabalho no disco para manter o código-fonte, os artefatos e as saídas usadas na execução. Em seguida, ele começa a executar etapas.

Execute cada etapa

As etapas são executadas sequencialmente, uma após a outra. Antes que uma etapa possa ser iniciada, todas as etapas anteriores devem ser concluídas (ou ignoradas).

Executar cada tarefa

As etapas são implementadas por tarefas. As próprias tarefas são implementadas como Node.js ou scripts do PowerShell. O sistema de tarefas roteia entradas e saídas para os scripts de suporte. Ele também fornece alguns serviços comuns, como alterar o caminho do sistema e criar variáveis de pipeline.

Cada etapa é executada no próprio processo, isolando-a do ambiente deixado pelas 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 têm um mecanismo para se comunicar com o agente: comandos de registro em log. Quando uma tarefa ou script grava um comando de log para padronizar, o agente executará qualquer ação solicitada.

Há um comando do agente para criar variáveis de pipeline. As variáveis de pipeline serão convertidas automaticamente em variáveis de ambiente na próxima etapa. Para definir uma variável myVar com um valor de myValue, um script pode fazer isso:

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

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

Relatar e coletar resultados

Cada etapa pode relatar avisos, erros e falhas. Erros e avisos são relatados para a página de resumo do pipeline, marcando a tarefa como "bem-sucedida com problemas". As falhas também são relatadas para a página de resumo, mas marcam a tarefa como "com falha". Uma etapa será uma falha se ela relatar explicitamente a falha (usando um comando ##vso) ou terminar o script com um código de saída diferente de zero.

Os logs e os resultados fluem de agente para serviço

Conforme as etapas são executadas, o agente está constantemente enviando linhas de saída para o serviço. É por isso que você pode ver um feed ao vivo do console. No final de cada etapa, toda a saída da etapa também é carregada como um arquivo de log. Os logs podem ser baixados depois que o pipeline é concluído. Outros itens que o agente pode carregar incluem artefatos e resultados de teste. Eles também estão disponíveis após a conclusão do pipeline.

Estado e condições

O agente controla o sucesso ou a falha de cada etapa. À medida que as etapas tiverem êxito com problemas ou falharem, o status do trabalho será atualizado. O trabalho sempre reflete o resultado "pior" de cada uma de suas etapas: se uma etapa falhar, o trabalho também falhará.

Antes de executar uma etapa, o agente marcará a condição dessa etapa para determinar se ela deve ser executada. Por padrão, uma etapa só será executada quando o status do trabalho for bem-sucedido ou tiver êxito com problemas. Muitos trabalhos têm etapas de limpeza que precisam ser executadas independentemente do que mais aconteceu para que possam especificar uma condição de "always()". As etapas de limpeza também podem ser definidas para execução apenas no cancelamento. Uma etapa de limpeza bem-sucedida não pode impedir que o trabalho falhe; os trabalhos nunca poderão voltar ao sucesso após entrarem em falha.

Tempos limite e desconexões

Cada trabalho tem um tempo limite. Se o trabalho não tiver sido concluído no tempo especificado, o servidor o cancelará. Ele tentará sinalizar o agente para parar e marcará o trabalho como cancelado. No lado do agente, isso significa cancelar todas as etapas restantes e carregar os demais resultados.

Os trabalhos têm um período de carência conhecido como o tempo limite de cancelamento para concluir qualquer trabalho de cancelamento. (Lembre-se de que as etapas podem ser marcadas para serem executadas mesmo no cancelamento.) Após o tempo limite mais o tempo limite de cancelamento, se o agente não tiver relatado que o trabalho foi interrompido, o servidor marcará o trabalho como uma falha.

Como o Azure Pipelines distribui o trabalho para computadores do agente, de tempos em tempos, os agentes podem parar de responder ao servidor. Isso pode acontecer se o computador host do agente desaparecer (perda de energia, VM desativada) ou se houver uma falha de rede. Para ajudar a detectar 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 recebe uma pulsação por cinco minutos consecutivos, ele pressupõe que o agente não voltará. O trabalho é marcado como uma falha, informando ao usuário que ele deve repetir o pipeline.

Gerenciar execuções por meio da CLI

Usando a CLI do Azure DevOps, você pode listar as execuções de pipeline em seu projeto e exibir detalhes sobre uma execução específica. Você também pode adicionar e excluir marcas em sua execução de pipeline.

Pré-requisitos

  • Você precisa ter instalado a extensão da CLI do Azure DevOps, conforme descrito em Introdução à CLI do Azure DevOps.
  • Entre no Azure DevOps usando az login.
  • Para os exemplos neste artigo, defina a organização padrão usando az devops configure --defaults organization=YourOrganizationURL.

Listar execuções de pipeline

Liste as execuções de pipeline em seu projeto com o comando az pipelines runs list. Para começar, confira Introdução à CLI do Azure DevOps.

az pipelines runs list [--branch]
                       [--org]
                       [--pipeline-ids]
                       [--project]
                       [--query-order {FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc, StartTimeDesc}]
                       [--reason {all, batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated, validateShelveset}]
                       [--requested-for]
                       [--result {canceled, failed, none, partiallySucceeded, succeeded}]
                       [--status {all, cancelling, completed, inProgress, none, notStarted, postponed}]
                       [--tags]
                       [--top]

Parâmetros opcionais

  • branch: filtre por builds para esse branch.
  • org: o URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=ORG_URL. Obrigatório se não estiver configurado como padrão ou selecionado usando git config. Exemplo: --org https://dev.azure.com/MyOrganizationName/.
  • pipeline-ids: IDs separadas por espaço de definições para as quais listar builds.
  • project: nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=NAME_OR_ID. Obrigatório se não estiver configurado como padrão ou selecionado usando git config.
  • query-order: defina a ordem na qual as execuções de pipeline são listadas. Os valores aceitos são FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc e StartTimeDesc.
  • reason: lista somente builds de lista por esse motivo especificado. Os valores aceitos são batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated e validateShelveset.
  • requested-for: limite para os builds solicitados para um usuário ou grupo especificado.
  • result: limite para os builds com um resultado especificado. Os valores aceitos são canceled, failed, none, partiallySucceeded e succeeded.
  • status: limite para os builds com um status especificado. Os valores aceitos são todos, cancelando, concluídos, inProgress, none, notStarted e adiados.
  • marcas: limite para os builds com cada uma das marcas especificadas. Espaço separado.
  • top: número máximo de builds a serem listados.

Exemplo

O comando a seguir lista as três primeiras execuções de pipeline que têm um status de concluído e um resultado de êxito e retorna o resultado no formato de tabela.

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

Mostrar detalhes da execução de pipeline

Mostre os detalhes de uma execução de pipeline em seu projeto com o comando az pipelines runs show. Para começar, confira Introdução à CLI do Azure DevOps.

az pipelines runs show --id
                       [--open]
                       [--org]
                       [--project]

Parâmetros

  • id: obrigatório. ID da execução de pipeline.
  • abrir: opcional. Abre a página de resultados do build no navegador da Web.
  • org: o URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=ORG_URL. Obrigatório se não estiver configurado como padrão ou selecionado usando git config. Exemplo: --org https://dev.azure.com/MyOrganizationName/.
  • project: nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=NAME_OR_ID. Obrigatório se não estiver configurado como padrão ou selecionado usando git config.

Exemplo

O comando a seguir mostra detalhes da execução de pipeline com a ID 123 e retorna os resultados no formato de tabela. Ele também abre o navegador da Web para a página de resultados do build.

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

Adicionar marca à execução de pipeline

Adicione uma marca a uma execução de pipeline em seu projeto com o comando az pipelines runs tag add. Para começar, confira Introdução à CLI do Azure DevOps.

az pipelines runs tag add --run-id
                          --tags
                          [--org]
                          [--project]

Parâmetros

  • run-id: obrigatório. ID da execução de pipeline.
  • marcas: obrigatórias. Marcas a serem adicionadas à execução de pipeline (valores separados por vírgula).
  • org: o URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=ORG_URL. Obrigatório se não estiver configurado como padrão ou selecionado usando git config. Exemplo: --org https://dev.azure.com/MyOrganizationName/.
  • project: nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=NAME_OR_ID. Obrigatório se não estiver configurado como padrão ou selecionado usando git config.

Exemplo

O comando a seguir adiciona a marca YAML à execução de pipeline com a ID 123 e retorna o resultado no formato JSON.

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

[
  "YAML"
]

Listar marcas de execução de pipeline

Liste as marcas de uma execução de pipeline em seu projeto com o comando az pipelines runs tag list. Para começar, confira Introdução à CLI do Azure DevOps.

az pipelines runs tag list --run-id
                           [--org]
                           [--project]

Parâmetros

  • run-id: obrigatório. ID da execução de pipeline.
  • org: o URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=ORG_URL. Obrigatório se não estiver configurado como padrão ou selecionado usando git config. Exemplo: --org https://dev.azure.com/MyOrganizationName/.
  • project: nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=NAME_OR_ID. Obrigatório se não estiver configurado como padrão ou selecionado usando git config.

Exemplo

O comando a seguir lista as marcas para a execução de pipeline com a ID 123 e retorna o resultado no formato de tabela.

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

Tags
------
YAML

Excluir marca da execução de pipeline

Exclua uma marca de uma execução de pipeline em seu projeto com o comando az pipelines runs tag delete. Para começar, confira Introdução à CLI do Azure DevOps.

az pipelines runs tag delete --run-id
                             --tag
                             [--org]
                             [--project]

Parâmetros

  • run-id: obrigatório. ID da execução de pipeline.
  • marca: obrigatória. Marca a ser excluída da execução de pipeline.
  • org: o URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=ORG_URL. Obrigatório se não estiver configurado como padrão ou selecionado usando git config. Exemplo: --org https://dev.azure.com/MyOrganizationName/.
  • project: nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=NAME_OR_ID. Obrigatório se não estiver configurado como padrão ou selecionado usando git config.

Exemplo

O comando a seguir exclui a marca YAML da execução de pipeline com a ID 123.

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