Pijplijnuitvoeringsvolgorde

  • Artikel

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

Uitvoeringen vertegenwoordigen één uitvoering van een pijplijn. Tijdens een uitvoering wordt de pijplijn verwerkt en verwerken agents een of meer taken. Een pijplijnuitvoering bevat taken, stappen en taken. Hiermee worden zowel CI-pijplijnen (continue integratie) als CD-pijplijnen (continue levering) uitgevoerd.

Overzicht van pijplijnen

Wanneer u een pijplijn uitvoert, gebeurt er veel onder de dekens. Hoewel u er vaak niets over hoeft te weten, is het af en toe handig om een overzicht te hebben. Op hoog niveau doet Azure Pipelines het volgende:

Aan de agentzijde doet een agent voor elke taak het volgende:

Taken kunnen slagen, mislukken of worden geannuleerd. Er zijn ook situaties waarin een taak mogelijk niet wordt voltooid. Als u weet hoe dit gebeurt, kunt u problemen oplossen.

Laten we elke actie een voor een opsplitsen.

De pijplijn verwerken

YAML-sjablonen uitvouwen

Als u een pijplijn wilt omzetten in een uitvoering, doorloopt Azure Pipelines verschillende stappen in deze volgorde:

  1. Vouw eerst sjablonen uit en evalueer sjabloonexpressies.
  2. Evalueer vervolgens afhankelijkheden op faseniveau om de eerste fase(s) te kiezen die moeten worden uitgevoerd.
  3. Voor elke fase die is geselecteerd om te worden uitgevoerd, gebeuren er twee dingen:
  4. Vouw voor elke taak die is geselecteerd om uit te voeren meerdere configuraties (strategy: matrix of strategy: parallel in YAML) uit in meerdere runtimetaken.
  5. Evalueer voor elke runtimetaak de voorwaarden om te bepalen of die taak in aanmerking komt om te worden uitgevoerd.
  6. Vraag een agent aan voor elke in aanmerking komende runtimetaak.

Wanneer runtimetaken zijn voltooid, ziet Azure Pipelines of er nieuwe taken zijn die in aanmerking komen om te worden uitgevoerd. Als dat het zo is, herhaalt u stap 4 tot en met 6 met de nieuwe taken. Zodra de fasen zijn voltooid, worden stap 2 en 6 herhaald voor eventuele nieuwe fasen.

Deze volgorde helpt bij het beantwoorden van een veelgestelde vraag: waarom kan ik bepaalde variabelen niet gebruiken in mijn sjabloonparameters? Stap 1, sjabloonuitbreiding, werkt alleen op de tekst van het YAML-document. Runtimevariabelen bestaan niet tijdens die stap. Na stap 1 zijn sjabloonparameters omgezet en bestaan niet meer.

Er wordt ook een ander veelvoorkomend probleem opgelost: waarom kan ik variabelen niet gebruiken om namen van serviceverbindingen/ omgevingen op te lossen? Resources zijn geautoriseerd voordat een fase kan worden uitgevoerd, dus variabelen op fase- en taakniveau zijn niet beschikbaar. Variabelen op pijplijnniveau kunnen worden gebruikt, maar alleen de variabelen die expliciet in de pijplijn zijn opgenomen. Variabelegroepen zijn zelf een resource die aan autorisatie onderhevig is, zodat de gegevens ervan ook niet beschikbaar zijn bij het controleren van de resourceautorisatie.

Een agent aanvragen

Wanneer Azure Pipelines een taak moet uitvoeren, wordt de pool om een agent gevraagd. (Servertaken zijn een uitzondering, omdat ze worden uitgevoerd op de Azure Pipelines-server zelf.) Door Microsoft gehoste en zelf-hostende agentpools werken iets anders.

Door Microsoft gehoste agentpoolaanvragen

Eerst controleert de service de parallelle taken van uw organisatie. Het telt alle actieve taken op alle door Microsoft gehoste agents op en vergelijkt dat met het aantal parallelle taken dat is aangeschaft. Als er geen beschikbare parallelle sleuven zijn, moet de taak wachten op een site om vrij te maken.

Zodra een parallelle site beschikbaar is, wordt de taak doorgestuurd naar het aangevraagde agenttype. Conceptueel is de door Microsoft gehoste pool één grote, wereldwijde pool van machines. (In werkelijkheid zijn er veel verschillende fysieke pools die zijn gesplitst op geografie en type besturingssysteem.) Op basis van de vmImage aangevraagde naam (in YAML) of poolnaam (in de klassieke editor), wordt een agent geselecteerd.

Poolselectie

Alle agents in de Microsoft-pool zijn nieuwe, nieuwe virtuele machines die nog geen pijplijnen hebben uitgevoerd. Wanneer de taak is voltooid, wordt de agent-VM verwijderd.

Aanvragen van zelf-hostende agentpools

Net als bij de door Microsoft gehoste pool controleert de service eerst de parallelle taken van uw organisatie. Het telt alle actieve taken op alle zelf-hostende agents op en vergelijkt dat met het aantal parallelle taken dat is aangeschaft. Als er geen beschikbare parallelle sleuven zijn, moet de taak wachten op een site om vrij te maken.

Zodra een parallelle site beschikbaar is, wordt de zelf-hostende pool onderzocht op een compatibele agent. Zelf-hostende agents bieden mogelijkheden. Dit zijn tekenreeksen die aangeven dat bepaalde software is geïnstalleerd of dat instellingen zijn geconfigureerd. De pijplijn heeft vereisten. Dit zijn de mogelijkheden die nodig zijn om de taak uit te voeren. Als er geen gratis agent kan worden gevonden waarvan de mogelijkheden overeenkomen met de vereisten van de pijplijn, blijft de taak wachten. Als er geen agents in de pool zijn waarvan de mogelijkheden overeenkomen met de vereisten, mislukt de taak.

Zelf-hostende agents worden doorgaans opnieuw gebruikt van uitvoering tot uitvoering. Voor zelf-hostende agents kan een pijplijntaak neveneffecten hebben, zoals het opwarmen van caches of het feit dat de meeste doorvoeringen al beschikbaar zijn in de lokale opslagplaats.

Het uitvoeren van een taak voorbereiden

Zodra een agent een taak heeft geaccepteerd, moet deze wat voorbereidingswerk doen. De agent downloadt (en slaat voor de volgende keer) alle taken op die nodig zijn om de taak uit te voeren. Er wordt werkruimte op de schijf gemaakt voor het opslaan van de broncode, artefacten en uitvoer die in de uitvoering worden gebruikt. Vervolgens worden de stappen uitgevoerd.

Elke stap uitvoeren

Stappen worden opeenvolgend uitgevoerd, achter elkaar. Voordat een stap kan worden gestart, moeten alle vorige stappen worden voltooid (of overgeslagen).

Elke taak uitvoeren

Stappen worden geïmplementeerd door taken. Taken zelf worden geïmplementeerd als Node.js- of PowerShell-scripts. Het taaksysteem routeert invoer en uitvoer naar de back-upscripts. Het biedt ook enkele algemene services, zoals het wijzigen van het systeempad en het maken van nieuwe pijplijnvariabelen.

Elke stap wordt uitgevoerd in een eigen proces, waarbij deze wordt geïsoleerd van de omgeving die in de vorige stappen is achtergelaten. Vanwege dit proces-per-stap-model blijven omgevingsvariabelen niet behouden tussen de stappen. Taken en scripts hebben echter een mechanisme om terug te communiceren met de agent: opdrachten voor logboekregistratie. Wanneer een taak of script een logboekopdracht schrijft om standaard uit te voeren, onderneemt de agent de gewenste actie.

Er is een agentopdracht om nieuwe pijplijnvariabelen te maken. Pijplijnvariabelen worden in de volgende stap automatisch geconverteerd naar omgevingsvariabelen. Als u een nieuwe variabele myVar wilt instellen met de waarde van myValue, kan een script dit doen:

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

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

Resultaten rapporteren en verzamelen

Elke stap kan waarschuwingen, fouten en fouten rapporteren. Fouten en waarschuwingen worden gerapporteerd op de overzichtspagina van de pijplijn, waarbij de taak wordt gemarkeerd als 'geslaagd met problemen'. Fouten worden ook gerapporteerd op de overzichtspagina, maar ze markeren de taak als 'mislukt'. Een stap is een fout als deze expliciet een fout rapporteert (met behulp van een ##vso opdracht) of het script beëindigt met een afsluitcode die niet nul is.

Logboeken en resultaten stromen van agent naar service

Terwijl de stappen worden uitgevoerd, verzendt de agent voortdurend uitvoerregels naar de service. Daarom kunt u een livefeed van de console zien. Aan het einde van elke stap wordt de volledige uitvoer van de stap ook geüpload als een logboekbestand. Logboeken kunnen worden gedownload zodra de pijplijn is voltooid. Andere items die de agent kan uploaden, zijn artefacten en testresultaten. Deze zijn ook beschikbaar nadat de pijplijn is voltooid.

Status en voorwaarden

De agent houdt het slagen of mislukken van elke stap bij. Als de stappen slagen bij problemen of mislukken, wordt de status van de taak bijgewerkt. De taak weerspiegelt altijd het 'slechtste' resultaat van elk van de stappen: als een stap mislukt, mislukt de taak ook.

Voordat een stap wordt uitgevoerd, controleert de agent de voorwaarde van die stap om te bepalen of deze moet worden uitgevoerd. Standaard wordt een stap alleen uitgevoerd wanneer de status van de taak is geslaagd of geslaagd met problemen. Veel taken hebben opschoningsstappen die moeten worden uitgevoerd, ongeacht wat er nog meer is gebeurd, zodat ze de voorwaarde 'altijd()' kunnen opgeven. Opschoningsstappen kunnen ook worden ingesteld om alleen te worden uitgevoerd bij annulering. Een geslaagde opschoningsstap kan niet voorkomen dat de taak mislukt; taken kunnen na het invoeren van een fout nooit meer worden voltooid.

Time-outs en verbroken verbindingen

Elke taak heeft een time-out. Als de taak niet binnen de opgegeven tijd is voltooid, annuleert de server de taak. Er wordt geprobeerd om de agent te laten stoppen en de taak wordt gemarkeerd als geannuleerd. Aan de agentzijde betekent dit het annuleren van alle resterende stappen en het uploaden van eventuele resterende resultaten.

Taken hebben een respijtperiode die bekend staat als de annuleringstime-out waarin alle annuleringswerkzaamheden moeten worden voltooid. (Houd er rekening mee dat stappen kunnen worden gemarkeerd om te worden uitgevoerd , zelfs bij annulering.) Na de time-out plus de time-out voor annuleren, als de agent niet heeft gemeld dat het werk is gestopt, markeert de server de taak als een fout.

Omdat Azure Pipelines werk distribueert naar agentmachines, kunnen agents van tijd tot tijd niet meer reageren op de server. Dit kan gebeuren als de hostmachine van de agent uitvalt (stroomuitval, VM uitgeschakeld) of als er een netwerkstoring is opgetreden. Om deze omstandigheden te detecteren, verzendt de agent één keer per minuut een heartbeat-bericht om de server te laten weten dat deze nog steeds actief is. Als de server vijf opeenvolgende minuten geen heartbeat ontvangt, wordt ervan uitgegaan dat de agent niet terugkomt. De taak wordt gemarkeerd als een fout, zodat de gebruiker weet dat hij de pijplijn opnieuw moet proberen.

Uitvoeringen beheren via de CLI

Met behulp van de Azure DevOps CLI kunt u de pijplijnuitvoeringen in uw project weergeven en details over een specifieke uitvoering weergeven. U kunt ook tags toevoegen en verwijderen in uw pijplijnuitvoering.

Vereisten

  • U moet de Azure DevOps CLI-extensie hebben geïnstalleerd, zoals beschreven in Aan de slag met Azure DevOps CLI.
  • Meld u aan bij Azure DevOps met behulp van az login.
  • Stel voor de voorbeelden in dit artikel de standaardorganisatie in met behulp van az devops configure --defaults organization=YourOrganizationURL.

Pijplijnuitvoeringen weergeven

Vermeld de pijplijnuitvoeringen in uw project met de opdracht az pipelines runs list . Zie Aan de slag met Azure DevOps CLI om aan de slag te gaan.

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]

Optionele parameters

  • branch: Filter op builds voor deze vertakking.
  • organisatie: Url van Azure DevOps-organisatie. U kunt de standaardorganisatie configureren met behulp van az devops configure -d organization=ORG_URL. Vereist als deze niet als standaard is geconfigureerd of wordt opgehaald met behulp van git config. Bijvoorbeeld: --org https://dev.azure.com/MyOrganizationName/.
  • pijplijn-id's: door ruimte gescheiden id's van definities waarvoor builds moeten worden vermeld.
  • project: naam of id van het project. U kunt het standaardproject configureren met behulp van az devops configure -d project=NAME_OR_ID. Vereist als deze niet als standaard is geconfigureerd of wordt opgehaald met behulp van git config.
  • queryvolgorde: definieer de volgorde waarin pijplijnuitvoeringen worden vermeld. Geaccepteerde waarden zijn FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc en StartTimeDesc.
  • reason: vermeld alleen builds voor deze opgegeven reden. Geaccepteerde waarden zijn batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated en validateShelveset.
  • requested-for: Beperk tot de builds die zijn aangevraagd voor een opgegeven gebruiker of groep.
  • result: Beperken tot de builds met een opgegeven resultaat. Geaccepteerde waarden worden geannuleerd, mislukt, geen, gedeeltelijk Geslaagd en geslaagd.
  • status: Beperk tot de builds met een opgegeven status. Geaccepteerde waarden zijn allemaal, annuleren, voltooid, inProgress, none, notStarted en uitgesteld.
  • tags: Beperk tot de builds met elk van de opgegeven tags. Spaties gescheiden.
  • top: maximum aantal builds dat u wilt vermelden.

Voorbeeld

De volgende opdracht geeft een lijst van de eerste drie pijplijnuitvoeringen met de status voltooid en een resultaat van geslaagd, en retourneert het resultaat in tabelindeling.

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

Details van pijplijnuitvoering weergeven

Geef de details weer voor een pijplijnuitvoering in uw project met de opdracht az pipelines runs show . Zie Aan de slag met Azure DevOps CLI om aan de slag te gaan.

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

Parameters

  • id: vereist. Id van de pijplijnuitvoering.
  • open: optioneel. Hiermee opent u de pagina met buildresultaten in uw webbrowser.
  • organisatie: Url van Azure DevOps-organisatie. U kunt de standaardorganisatie configureren met behulp van az devops configure -d organization=ORG_URL. Vereist als deze niet als standaard is geconfigureerd of wordt opgehaald met behulp van git config. Bijvoorbeeld: --org https://dev.azure.com/MyOrganizationName/.
  • project: naam of id van het project. U kunt het standaardproject configureren met behulp van az devops configure -d project=NAME_OR_ID. Vereist als deze niet als standaard is geconfigureerd of wordt opgehaald met behulp van git config.

Voorbeeld

De volgende opdracht toont details voor de pijplijnuitvoering met de id 123 en retourneert de resultaten in tabelindeling. Ook wordt in uw webbrowser de pagina met buildresultaten geopend.

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

Tag toevoegen aan pijplijnuitvoering

Voeg een tag toe aan een pijplijnuitvoering in uw project met de opdracht az pipelines runs tag add . Zie Aan de slag met Azure DevOps CLI om aan de slag te gaan.

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

Parameters

  • run-id: vereist. Id van de pijplijnuitvoering.
  • tags: vereist. Tags die moeten worden toegevoegd aan de pijplijnuitvoering (door komma's gescheiden waarden).
  • organisatie: Url van Azure DevOps-organisatie. U kunt de standaardorganisatie configureren met behulp van az devops configure -d organization=ORG_URL. Vereist als deze niet als standaard is geconfigureerd of wordt opgehaald met behulp van git config. Bijvoorbeeld: --org https://dev.azure.com/MyOrganizationName/.
  • project: naam of id van het project. U kunt het standaardproject configureren met behulp van az devops configure -d project=NAME_OR_ID. Vereist als deze niet als standaard is geconfigureerd of wordt opgehaald met behulp van git config.

Voorbeeld

Met de volgende opdracht wordt de tag YAML toegevoegd aan de pijplijnuitvoering met id 123 en wordt het resultaat in JSON-indeling geretourneerd.

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

[
  "YAML"
]

Pijplijnuitvoeringstags weergeven

Vermeld de tags voor een pijplijnuitvoering in uw project met de opdracht az pipelines runs tag list . Zie Aan de slag met Azure DevOps CLI om aan de slag te gaan.

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

Parameters

  • run-id: vereist. Id van de pijplijnuitvoering.
  • organisatie: Url van Azure DevOps-organisatie. U kunt de standaardorganisatie configureren met behulp van az devops configure -d organization=ORG_URL. Vereist als deze niet als standaard is geconfigureerd of wordt opgehaald met behulp van git config. Bijvoorbeeld: --org https://dev.azure.com/MyOrganizationName/.
  • project: naam of id van het project. U kunt het standaardproject configureren met behulp van az devops configure -d project=NAME_OR_ID. Vereist als deze niet als standaard is geconfigureerd of wordt opgehaald met behulp van git config.

Voorbeeld

Met de volgende opdracht worden de tags voor de pijplijnuitvoering met id 123 weergegeven en wordt het resultaat in tabelindeling geretourneerd.

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

Tags
------
YAML

Tag verwijderen uit pijplijnuitvoering

Verwijder een tag uit een pijplijnuitvoering in uw project met de opdracht az pipelines runs tag delete . Zie Aan de slag met Azure DevOps CLI om aan de slag te gaan.

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

Parameters

  • run-id: vereist. Id van de pijplijnuitvoering.
  • tag: vereist. Tag die moet worden verwijderd uit de pijplijnuitvoering.
  • org: Azure DevOps-organisatie-URL. U kunt de standaardorganisatie configureren met behulp van az devops configure -d organization=ORG_URL. Vereist als deze niet als standaard is geconfigureerd of wordt opgehaald met behulp van git config. Bijvoorbeeld: --org https://dev.azure.com/MyOrganizationName/.
  • project: naam of id van het project. U kunt het standaardproject configureren met behulp van az devops configure -d project=NAME_OR_ID. Vereist als deze niet als standaard is geconfigureerd of wordt opgehaald met behulp van git config.

Voorbeeld

Met de volgende opdracht verwijdert u de YAML-tag uit de pijplijnuitvoering met id 123.

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