Fasen, afhankelijkheden en voorwaarden toevoegen

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

Een fase is een logische grens in een Azure DevOps-pijplijn. Fasen kunnen worden gebruikt voor het groeperen van acties in uw softwareontwikkelingsproces (bijvoorbeeld het bouwen van de app, het uitvoeren van tests, implementeren naar preproductie). Elke fase bevat een of meer taken.

Wanneer u meerdere fasen in een pijplijn definieert, worden ze standaard één na de andere uitgevoerd. Fasen kunnen ook van elkaar afhankelijk zijn. U kunt het dependsOn trefwoord gebruiken om afhankelijkheden te definiëren. Fasen kunnen ook worden uitgevoerd op basis van het resultaat van een vorige fase met voorwaarden.

Zie Configureren en betalen voor parallelle taken voor meer informatie over de werking van fasen met parallelle taken en licenties.

Als u wilt achterhalen hoe fasen zich verhouden tot andere onderdelen van een pijplijn, zoals taken, raadpleegt u de concepten van belangrijke pijplijnen.

U kunt ook meer informatie vinden over de relatie tussen fasen en onderdelen van een pijplijn in het artikel over YAML-schemafasen.

YAML

U kunt pijplijntaken in fasen indelen. Fasen zijn de belangrijkste divisies in een pijplijn: bouw deze app, voer deze tests uit en implementeer in preproductie zijn goede voorbeelden van fasen. Ze zijn logische grenzen in uw pijplijn, waar u de pijplijn kunt onderbreken en verschillende controles kunt uitvoeren.

Elke pijplijn heeft ten minste één fase, zelfs als u deze niet expliciet definieert. U kunt fasen ook rangschikken in een afhankelijkheidsgrafiek, zodat de ene fase vóór de andere wordt uitgevoerd. Er geldt een limiet van 256 taken voor een fase.

Klassiek

Organiseer de implementatietaken in uw release-pijplijn in fasen. Fasen zijn de belangrijkste afdelingen in uw release-pijplijn: functionele tests uitvoeren, implementeren in preproductie en implementeren in productie zijn goede voorbeelden van releasefasen.

Een fase in een release-pijplijn bestaat uit taken en taken.

Goedkeuringen en gates, implementatievoorwaarden en triggers en beleid in de wachtrij plaatsen wanneer een release in een fase wordt geïmplementeerd.

Fasen opgeven

YAML

In het eenvoudigste geval hebt u geen logische grenzen in uw pijplijn nodig. In dat geval hoeft u het stage trefwoord niet expliciet te gebruiken. U kunt de taken in uw YAML-bestand rechtstreeks opgeven.

# this has one implicit stage and one implicit job
pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

# this pipeline has one implicit stage
jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

Als u uw pijplijn in meerdere fasen ordent, gebruikt u het stages trefwoord.

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

Als u ervoor kiest om een pool op faseniveau op te geven, gebruiken alle taken die in die fase zijn gedefinieerd die pool, tenzij deze op taakniveau zijn opgegeven.

stages:
- stage: A
  pool: StageAPool
  jobs:
  - job: A1 # will run on "StageAPool" pool based on the pool defined on the stage
  - job: A2 # will run on "JobPool" pool
    pool: JobPool

De volledige syntaxis voor het opgeven van een fase is:

stages:
- stage: string  # name of the stage, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  pool: string | pool
  variables: { string: string } | [ variable | variableReference ] 
  jobs: [ job | templateReference]

Klassiek

Als u een fase wilt toevoegen aan uw release-pijplijn, selecteert u de release-pijplijn op de pagina Releases , selecteert u de actie om deze te bewerken en selecteert u vervolgens het tabblad Pijplijn . Hoewel het belangrijkste onderdeel van het definiëren van een fase de automatiseringstaken zijn, kunt u ook verschillende eigenschappen en opties configureren voor een fase in een release-pijplijn. U kunt:

• Bewerk indien nodig de naam van de fase.
• Wijs één gebruiker of groep aan als de eigenaar van de fase. Fase-eigenaren krijgen een melding wanneer een implementatie in die fase mislukt. De eigenaar van een fase wordt niet automatisch geleverd met machtigingen.
• Verwijder de fase uit de pijplijn.
• Wijzig de volgorde van fasen.
• Sla een kopie van de fase op als een fasesjabloon.
• Beheer de beveiligingsinstellingen voor de fase.

Afhankelijkheden opgeven

YAML

Wanneer u meerdere fasen in een pijplijn definieert, worden ze standaard opeenvolgend uitgevoerd in de volgorde waarin u ze definieert in het YAML-bestand. De uitzondering hierop is wanneer u afhankelijkheden toevoegt. Met afhankelijkheden worden fasen uitgevoerd in de volgorde van de dependsOn vereisten.

Pijplijnen moeten ten minste één fase bevatten zonder afhankelijkheden.

De syntaxis voor het definiëren van meerdere fasen en de bijbehorende afhankelijkheden is:

stages:
- stage: string
  dependsOn: string
  condition: string

Voorbeeldfasen die opeenvolgend worden uitgevoerd:

# if you do not use a dependsOn keyword, stages run in the order they are defined
stages:
- stage: QA
  jobs:
  - job:
    ...

- stage: Prod
  jobs:
  - job:
    ...

Voorbeeldfasen die parallel worden uitgevoerd:

stages:
- stage: FunctionalTest
  jobs:
  - job:
    ...

- stage: AcceptanceTest
  dependsOn: []    # this removes the implicit dependency on previous stage and causes this to run in parallel
  jobs:
  - job:
    ...

Voorbeeld van fan-out en fan-in:

stages:
- stage: Test

- stage: DeployUS1
  dependsOn: Test    # this stage runs after Test

- stage: DeployUS2
  dependsOn: Test    # this stage runs in parallel with DeployUS1, after Test

- stage: DeployEurope
  dependsOn:         # this stage runs after DeployUS1 and DeployUS2
  - DeployUS1
  - DeployUS2

Klassiek

U beheert de afhankelijkheden door de triggers in elke fase van de release-pijplijn in te stellen:

• Fasen worden uitgevoerd met een trigger of door handmatig te worden gestart.
• Met een After-releasetrigger wordt een fase gestart zodra de release wordt gestart, parallel met andere fasen met after release-trigger .
• Met een Na-fasetrigger wordt een fase gestart nadat alle afhankelijke fasen zijn voltooid. Hiermee kunt u fan-out en fan-in gedrag modelleren voor fasen.

Voorwaarden definiëren

U kunt de voorwaarden opgeven waaronder elke fase wordt uitgevoerd met expressies. Standaard wordt een fase uitgevoerd als deze niet afhankelijk is van een andere fase of als alle fasen waarvan deze afhankelijk is, zijn voltooid en geslaagd. U kunt dit gedrag aanpassen door af te dwingen dat een fase wordt uitgevoerd, zelfs als een vorige fase mislukt of door een aangepaste voorwaarde op te geven.

Als u de standaardvoorwaarde van de voorgaande stappen voor een fase aanpast, verwijdert u de voorwaarden voor voltooiing en geslaagd. Dus als u een aangepaste voorwaarde gebruikt and(succeeded(),custom_condition) , is het gebruikelijk om te controleren of de vorige fase is uitgevoerd. Anders wordt de fase uitgevoerd, ongeacht het resultaat van de vorige fase.

Notitie

Voorwaarden voor mislukt ('JOBNAME/STAGENAME') en geslaagd ('JOBNAME/STAGENAME'), zoals wordt weergegeven in het volgende voorbeeld werken alleen voor YAML-pijplijnen.

YAML

Voorbeeld van het uitvoeren van een fase op basis van de status van het uitvoeren van een vorige fase:

stages:
- stage: A

# stage B runs if A fails
- stage: B
  condition: failed()

# stage C runs if B succeeds
- stage: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')

Voorbeeld van het gebruik van een aangepaste voorwaarde:

stages:
- stage: A

- stage: B
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))

Klassiek

Wanneer u na release of na fasetriggers opgeeft, kunt u ook de vertakkingsfilters opgeven voor de artefacten die in de release worden gebruikt. Releases worden alleen geïmplementeerd in een fase wanneer aan de vertakkingsfilters wordt voldaan.

Wachtrijbeleid opgeven

YAML

YAML-pijplijnen bieden geen ondersteuning voor wachtrijbeleid. Elke uitvoering van een pijplijn is onafhankelijk van en niet op de hoogte van andere uitvoeringen. Met andere woorden, uw twee opeenvolgende doorvoeringen kunnen twee pijplijnen activeren, en beide zullen dezelfde reeks fasen uitvoeren zonder op elkaar te wachten. Hoewel we werken om wachtrijbeleid naar YAML-pijplijnen te brengen, raden we u aan handmatige goedkeuringen te gebruiken om de volgorde van de uitvoering handmatig te ordenen en te beheren als dit van belang is.

Klassiek

In sommige gevallen kunt u mogelijk sneller builds genereren dan ze kunnen worden geïmplementeerd. U kunt ook meerdere agents configureren en bijvoorbeeld releases maken van dezelfde releasepijplijn voor implementatie van verschillende artefacten. In dergelijke gevallen is het handig om te bepalen hoe meerdere releases in een wachtrij worden geplaatst. Wachtrijbeleid geeft u die controle.

De opties die u kunt kiezen voor een wachtrijbeleid zijn:

• Aantal parallelle implementaties: gebruik deze optie als u dynamisch nieuwe resources in uw fase inricht en deze fysiek in staat is om de implementatie van meerdere releases parallel te verwerken, maar u wilt het aantal parallelle implementaties beperken.

• Als u een maximum aantal implementaties opgeeft, worden er nog twee opties weergegeven:

  • Alles op volgorde implementeren: gebruik deze optie als u alle releases opeenvolgend wilt implementeren in dezelfde gedeelde fysieke resources. Door de builds op zijn beurt te implementeren, zorgt u er één na de andere voor dat twee implementatietaken niet tegelijkertijd op dezelfde fysieke resources zijn gericht, zelfs als er meerdere build- en releaseagents beschikbaar zijn. U zorgt er ook voor dat goedkeuringsaanvragen voor de fase vooraf in volgorde worden verzonden.

  • Implementeer de nieuwste versie en annuleer de andere: gebruik deze optie als u sneller builds produceert dan releases en u alleen de nieuwste build wilt implementeren.

Als u wilt weten hoe deze opties werken, kunt u een scenario overwegen waarin R1, R2, ..., R5 van één release-pijplijn snel achter elkaar wordt gemaakt. Stel dat de eerste fase in deze pijplijn de naam QA heeft en dat er zowel predeployment- als postimplementatiekeurders zijn gedefinieerd.

• Als u geen limiet opgeeft voor het aantal parallelle implementaties, worden alle vijf goedkeuringsaanvragen verzonden zodra de releases worden gemaakt. Als de goedkeurders alle releases goedkeuren, worden ze allemaal parallel geïmplementeerd in de QA-fase . (als de Qa-fase heeft geen predeployment goedkeurders gedefinieerd, alle vijf releases worden automatisch parallel in deze fase geïmplementeerd).

• Als u een limiet opgeeft en Alles op volgorde implementeert en de limiet al is bereikt, wordt de goedkeuring van de voorlopige implementatie voor release R1 eerst verzonden. Nadat deze goedkeuring is voltooid, wordt de implementatie van release R1 in de QA-fase gestart. Vervolgens wordt er een aanvraag voor goedkeuring na de implementatie verzonden voor release R1. Pas nadat deze goedkeuring na de implementatie is voltooid, wordt de uitvoering van release R2 gestart en wordt de goedkeuring van de predeployment verzonden. Het proces blijft hetzelfde voor alle releases op zijn beurt.

• Als u een limiet opgeeft en de meest recente implementaties opgeeft en de anderen annuleert en de limiet al is bereikt, worden R2, R3 en R4 overgeslagen en wordt de goedkeuring van de predeployment voor R5 in de QA-fase verzonden direct nadat de goedkeuring na de implementatie voor release R1 is voltooid.

Goedkeuringen opgeven

YAML

U kunt handmatig bepalen wanneer een fase moet worden uitgevoerd met behulp van goedkeuringscontroles. Dit wordt vaak gebruikt om implementaties naar productieomgevingen te beheren. Controles zijn een mechanisme dat beschikbaar is voor de resource-eigenaar om te bepalen of en wanneer een fase in een pijplijn een resource kan gebruiken. Als eigenaar van een resource, zoals een omgeving, kunt u controles definiëren waaraan moet worden voldaan voordat een fase die die resource verbruikt, kan worden gestart.

Momenteel worden handmatige goedkeuringscontroles ondersteund in omgevingen. Zie Goedkeuringen voor meer informatie.

Klassiek

U kunt handmatige goedkeuringen toevoegen aan het begin of einde van elke fase in de pijplijn. Zie het overzicht van releasegoedkeuringen en poorten voor meer informatie.