Delen via


stages.stage definition

Fasen zijn een verzameling gerelateerde taken. Fasen worden standaard opeenvolgend uitgevoerd. Elke fase wordt pas gestart nadat de vorige fase is voltooid, tenzij anders is opgegeven via de eigenschap dependsOn.

stages:
- stage: string # Required as first property. ID of the stage.
  displayName: string # Human-readable name for the stage.
  pool: string | pool # Pool where jobs in this stage will run unless otherwise specified.
  dependsOn: string | [ string ] # Any stages which must complete before this one.
  condition: string # Evaluate this condition expression to determine whether to run this stage.
  variables: variables | [ variable ] # Stage-specific variables.
  jobs: [ job | deployment | template ] # Jobs which make up the stage.
  lockBehavior: sequential | runLatest # Behavior lock requests from this stage should exhibit in relation to other exclusive lock requests.
  trigger: manual | automatic # Stage trigger manual or automatic (default).
  isSkippable: boolean # Setting false prevents the stage from being skipped. By default it's always true.
  templateContext: # Stage related information passed from a pipeline when extending a template.
stages:
- stage: string # Required as first property. ID of the stage.
  displayName: string # Human-readable name for the stage.
  pool: string | pool # Pool where jobs in this stage will run unless otherwise specified.
  dependsOn: string | [ string ] # Any stages which must complete before this one.
  condition: string # Evaluate this condition expression to determine whether to run this stage.
  variables: variables | [ variable ] # Stage-specific variables.
  jobs: [ job | deployment | template ] # Jobs which make up the stage.
  lockBehavior: sequential | runLatest # Behavior lock requests from this stage should exhibit in relation to other exclusive lock requests.
  templateContext: # Stage related information passed from a pipeline when extending a template.
stages:
- stage: string # Required as first property. ID of the stage.
  displayName: string # Human-readable name for the stage.
  pool: string | pool # Pool where jobs in this stage will run unless otherwise specified.
  dependsOn: string | [ string ] # Any stages which must complete before this one.
  condition: string # Evaluate this condition expression to determine whether to run this stage.
  variables: variables | [ variable ] # Stage-specific variables.
  jobs: [ job | deployment | template ] # Jobs which make up the stage.

Definities die naar deze definitie verwijzen: fasen

Eigenschappen

stage tekenreeks. Vereist als eerste eigenschap.
id van de fase.

displayName tekenreeks.
leesbare naam voor de fase.

pool zwembad.
pool waarin taken in deze fase worden uitgevoerd, tenzij anders is opgegeven.

dependsOn tekenreeks | tekenreekslijst.
alle fasen die vóór deze moeten worden voltooid. Standaard worden fasen opeenvolgend uitgevoerd in de volgorde die in de pijplijn is gedefinieerd. Geef dependsOn: [] op voor een fase als deze niet afhankelijk moet zijn van de vorige fase in de pijplijn.

condition tekenreeks.
Evalueer deze voorwaardeexpressie om te bepalen of deze fase moet worden uitgevoerd.

variables variabelen.
fasespecifieke variabelen.

jobs taken.
Taken waaruit de fase bestaat.

lockBehavior tekenreeks.
Gedragsvergrendelingsaanvragen uit deze fase moeten worden weergegeven ten opzichte van andere exclusieve vergrendelingsaanvragen. sequentiële | runLatest.

trigger tekenreeks.
fasetrigger handmatig of automatisch (standaard). handmatig | Automatisch.

isSkippable booleaanse.
Instelling false voorkomt dat de fase wordt overgeslagen. Standaard is dit altijd waar.

templateContext templateContext.
gerelateerde informatie die is doorgegeven vanuit een pijplijn bij het uitbreiden van een sjabloon. Zie voor meer informatie over templateContextuitgebreide YAML Pipelines-sjablonen nu contextinformatie kunnen worden doorgegeven voor fasen, taken en implementaties en -sjablonen- TemplateContext gebruiken om eigenschappen door te geven aan sjablonen.

Opmerkingen

Zie voor meer informatie over templateContextuitgebreide YAML Pipelines-sjablonen nu contextinformatie kunnen worden doorgegeven voor fasen, taken en implementaties en -sjablonen- TemplateContext gebruiken om eigenschappen door te geven aan sjablonen.

Gebruik goedkeuringscontroles om handmatig te bepalen wanneer een fase moet worden uitgevoerd. Deze controles worden vaak gebruikt om implementaties naar productieomgevingen te beheren.

Controles zijn een mechanisme dat beschikbaar is voor de resource-eigenaar. Ze bepalen wanneer een fase in een pijplijn een resource verbruikt. Als eigenaar van een resource zoals een omgeving kunt u controles definiëren die vereist zijn voordat een fase die de resource verbruikt, kan worden gestart.

Momenteel worden handmatige goedkeuringscontroles ondersteund voor omgevingen. Zie Goedkeuringenvoor meer informatie.

Exclusief slot

In YAML-pijplijnen worden controles gebruikt om de uitvoering van fasen op beveiligde resources te beheren. Een van de algemene controles die u kunt gebruiken, is een exclusieve vergrendelingscontrole. Met deze controle kan slechts één uitvoering vanuit de pijplijn worden uitgevoerd. Wanneer meerdere uitvoeringen tegelijkertijd in een omgeving proberen te implementeren, annuleert de controle alle oude uitvoeringen en kan de meest recente uitvoering worden geïmplementeerd.

U kunt het gedrag van de exclusieve vergrendelingscontrole configureren met behulp van de eigenschap lockBehavior, die twee waarden heeft:

  • runLatest: alleen de meest recente uitvoering verkrijgt de vergrendeling voor de resource. Dit is de standaardwaarde als er geen lockBehavior is opgegeven.
  • sequential: alle uitvoeringen verkrijgen de vergrendeling sequentieel naar de beveiligde resource.

Het annuleren van oude uitvoeringen is een goede benadering wanneer uw releases cumulatief zijn en alle codewijzigingen van eerdere uitvoeringen bevatten. Er zijn echter enkele pijplijnen waarin codewijzigingen niet cumulatief zijn. Door de eigenschap lockBehavior te configureren, kunt u ervoor kiezen om alle uitvoeringen te laten doorgaan en opeenvolgend te implementeren in een omgeving, of het vorige gedrag van het annuleren van oude uitvoeringen behouden en alleen de meest recente uitvoeringen toestaan. Een waarde van sequential impliceert dat alle uitvoeringen de vergrendeling opeenvolgend verkrijgen voor de beveiligde resource. Een waarde van runLatest impliceert dat alleen de meest recente uitvoering de vergrendeling voor de resource verkrijgt.

Als u exclusieve vergrendelingscontrole wilt gebruiken bij sequential implementaties of runLatest, voert u de volgende stappen uit:

  1. Schakel de exclusieve vergrendelingscontrole in voor de omgeving (of een andere beveiligde resource).
  2. Geef in het YAML-bestand voor de pijplijn een nieuwe eigenschap op met de naam lockBehavior. Dit kan worden opgegeven voor de hele pijplijn of voor een bepaalde fase:

Instellen op een fase:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Instellen op de pijplijn:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Exclusief slot op faseniveau

Voor sommige gebruiksscenario's is een pijplijn vereist om slechts één keer toegang te krijgen tot een specifieke resource op een bepaald moment. Ter ondersteuning van deze case hebben we de exclusieve vergrendelingscontrole beschreven in de vorige sectie.

Er ontstaat een vergelijkbare situatie wanneer slechts één pijplijnuitvoering op elk moment toegang moet krijgen tot een fase. Als u bijvoorbeeld een fase hebt die wordt geïmplementeerd in een Azure-resourcegroep, kunt u voorkomen dat meerdere pijplijnuitvoeringen tegelijkertijd dezelfde resourcegroep bijwerken. Op dit moment moet u hiervoor een proxyresource gebruiken, zoals een omgeving, en de exclusieve vergrendelingscontrole op die omgeving plaatsen. Deze aanpak kan tijdrovend zijn, complexiteit toevoegen en onderhoudsinspanningen verhogen.

Als u ervoor wilt zorgen dat slechts één pijplijnuitvoering tegelijk toegang heeft tot een fase, kunt u de exclusieve vergrendeling opgeven op faseniveau. Als u een fase met een id hebt en de bijbehorende eigenschap lockBehavior opgeeft, wordt automatisch een vergrendeling voor die fase gemaakt. Het sequentiële gedrag blijft consistent voor zowel vergrendelingen op resourceniveau als op faseniveau. Het runLatest gedrag verschilt echter, omdat alleen runLatest builds voor dezelfde vertakking worden geannuleerd, niet voor alle vertakkingen van de pijplijn.

Voorbeelden

In dit voorbeeld worden drie fasen uitgevoerd, één na elkaar. In de middelste fase worden twee taken parallel uitgevoerd.

stages:
- stage: Build
  jobs:
  - job: BuildJob
    steps:
    - script: echo Building!
- stage: Test
  jobs:
  - job: TestOnWindows
    steps:
    - script: echo Testing on Windows!
  - job: TestOnLinux
    steps:
    - script: echo Testing on Linux!
- stage: Deploy
  jobs:
  - job: Deploy
    steps:
    - script: echo Deploying the code!

In dit voorbeeld worden twee fasen parallel uitgevoerd. Kortheid: de taken en stappen worden weggelaten.

stages:
- stage: BuildWin
  displayName: Build for Windows
- stage: BuildMac
  displayName: Build for Mac
  dependsOn: [] # by specifying an empty array, this stage doesn't depend on the stage before it

Zie ook

Meer informatie over fasen, voorwaardenen variabelen.