Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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 templateContext
uitgebreide 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 templateContext
uitgebreide 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 geenlockBehavior
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:
- Schakel de exclusieve vergrendelingscontrole in voor de omgeving (of een andere beveiligde resource).
- 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.