Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Phasen sind eine Sammlung verwandter Aufträge. Standardmäßig werden Phasen sequenziell ausgeführt. Jede Phase beginnt erst nach Abschluss der vorherigen Phase, sofern nicht anderweitig über die eigenschaft dependsOn
angegeben.
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.
Definitionen, die auf diese Definition verweisen: Phasen
Eigenschaften
stage
Zeichenfolge. Erforderlich als erste Eigenschaft.
-ID der Phase.
displayName
Zeichenfolge.
Lesbarer Name für die Stufe.
pool
Pool-.
Pool, in dem Aufträge in dieser Phase ausgeführt werden, sofern nichts anderes angegeben ist.
dependsOn
Zeichenfolge | Zeichenfolgenliste.
Alle Phasen, die vor dieser Phase abgeschlossen werden müssen. Standardmäßig werden Phasen sequenziell in der in der Pipeline definierten Reihenfolge ausgeführt. Geben Sie dependsOn: []
für eine Phase an, wenn sie nicht von der vorherigen Phase in der Pipeline abhängen soll.
condition
Zeichenfolge.
Diesen Bedingungsausdruck auswerten, um zu bestimmen, ob diese Phase ausgeführt werden soll.
variables
Variablen.
phasenspezifische Variablen.
jobs
Aufträge.
Jobs, aus denen die Bühne besteht.
lockBehavior
Zeichenfolge.
Verhaltenssperranforderungen aus dieser Phase sollten in Bezug auf andere exklusive Sperranforderungen angezeigt werden. sequenzielle | runLatest.
trigger
Zeichenfolge.
Phasenauslöser manuell oder automatisch (Standard). manual | Automatisch.
isSkippable
booleschen.
Einstellung "false" verhindert, dass die Phase übersprungen wird. Standardmäßig ist sie immer wahr.
templateContext
templateContext.
Phasenbezogene Informationen, die von einer Pipeline übergeben werden, wenn eine Vorlage erweitert wird. Weitere Informationen zu templateContext
finden Sie unter Vorlagen für erweiterte YAML-Pipelines können nun Kontextinformationen für Phasen, Aufträge und Bereitstellungen und Vorlagen übergeben werden . Verwenden Sie templateContext, um Eigenschaften an Vorlagenzu übergeben.
Bemerkungen
Weitere Informationen zu templateContext
finden Sie unter Vorlagen für erweiterte YAML-Pipelines können nun Kontextinformationen für Phasen, Aufträge und Bereitstellungen und Vorlagen übergeben werden . Verwenden Sie templateContext, um Eigenschaften an Vorlagenzu übergeben.
Verwenden Sie Genehmigungsprüfungen, um manuell zu steuern, wann eine Phase ausgeführt werden soll. Diese Überprüfungen werden häufig verwendet, um Bereitstellungen in Produktionsumgebungen zu steuern.
Prüfungen sind ein Mechanismus, der dem Ressourcenbesitzerzur Verfügung steht. Sie steuern, wann eine Phase in einer Pipeline eine Ressource nutzt. Als Besitzer einer Ressource wie einer Umgebung können Sie Prüfungen definieren, die vor einer Phase erforderlich sind, die die Ressource verbraucht.
Derzeit werden manuelle Genehmigungsprüfungen in Umgebungenunterstützt. Weitere Informationen finden Sie unter Genehmigungen.
Exklusive Sperre
In YAML-Pipelines werden Prüfungen verwendet, um die Ausführung von Phasen auf geschützten Ressourcenzu steuern. Eine der allgemeinen Prüfungen, die Sie verwenden können, ist eine exklusive Sperrprüfung. Mit dieser Überprüfung kann nur eine einzelne Ausführung aus der Pipeline fortgesetzt werden. Wenn mehrere Ausführungen versuchen, gleichzeitig in einer Umgebung bereitzustellen, bricht die Überprüfung alle alten Ausführungen ab und lässt die neueste Ausführung zu.
Sie können das Verhalten der exklusiven Sperrprüfung mithilfe der eigenschaft lockBehavior
konfigurieren, die zwei Werte aufweist:
-
runLatest
– Nur die neueste Ausführung erwirbt die Sperre für die Ressource. Dies ist der Standardwert, wenn keinelockBehavior
angegeben wird. -
sequential
– Alle Ausgeführten erwerben die Sperre sequenziell mit der geschützten Ressource.
Das Abbrechen alter Läufe ist ein guter Ansatz, wenn Ihre Versionen kumulativ sind und alle Codeänderungen aus vorherigen Ausführungen enthalten. Es gibt jedoch einige Pipelines, in denen Codeänderungen nicht kumulativ sind. Wenn Sie die eigenschaft lockBehavior
konfigurieren, können Sie festlegen, dass alle Ausführungen fortgesetzt und sequenziell in einer Umgebung bereitgestellt werden können, oder das vorherige Verhalten beim Abbrechen alter Ausführungen beibehalten und nur die neueste Ausführung zulassen. Ein Wert von sequential
impliziert, dass alle Ausführungen die Sperre sequenziell an die geschützte Ressource abrufen. Ein Wert von runLatest
impliziert, dass nur die neueste Ausführung die Sperre für die Ressource erhält.
Führen Sie die folgenden Schritte aus, um die exklusive Sperrüberprüfung mit sequential
Bereitstellungen oder runLatest
zu verwenden:
- Aktivieren Sie die exklusive Sperrüberprüfung für die Umgebung (oder eine andere geschützte Ressource).
- Geben Sie in der YAML-Datei für die Pipeline eine neue Eigenschaft namens
lockBehavior
an. Dies kann für die gesamte Pipeline oder für eine bestimmte Phase angegeben werden:
Auf einer Stufe festlegen:
stages:
- stage: A
lockBehavior: sequential
jobs:
- job: Job
steps:
- script: Hey!
Für die Pipeline festlegen:
lockBehavior: runLatest
stages:
- stage: A
jobs:
- job: Job
steps:
- script: Hey!
Exklusive Sperre auf Stufenebene
In einigen Anwendungsfällen muss eine Pipeline nur einmal auf eine bestimmte Ressource zugreifen. Um diesen Fall zu unterstützen, haben wir die exklusive Sperrüberprüfung, die im vorherigen Abschnitt beschrieben ist.
Eine ähnliche Situation tritt auf, wenn jeweils nur eine Pipelineausführung auf eine Phase zugreifen sollte. Wenn Sie beispielsweise eine Phase haben, die für eine Azure-Ressourcengruppe bereitgestellt wird, sollten Sie verhindern, dass mehrere Pipelineausführungen gleichzeitig dieselbe Ressourcengruppe aktualisieren. Zurzeit erfordert dies die Verwendung einer Proxyressource, z. B. einer Umgebung, und das Platzieren der exklusiven Sperrüberprüfung in dieser Umgebung. Dieser Ansatz kann zeitaufwendig sein, Komplexität hinzufügen und wartungsintensive Anstrengungen erhöhen.
Wenn Sie sicherstellen müssen, dass jeweils nur eine einzelne Pipeline ausgeführt wird, auf eine Phase zugreifen kann, können Sie die exklusive Sperre auf Stufesebene angeben. Wenn Sie eine Phase mit einer ID haben und deren lockBehavior
-Eigenschaft angeben, wird automatisch eine Sperre für diese Phase erstellt. Das sequenzielle Verhalten bleibt für Sperren auf Ressourcenebene und Stufe konsistent. Das runLatest
Verhalten unterscheidet sich jedoch, da nur runLatest
Builds für dieselbe Verzweigung abgebrochen werden, nicht für alle Verzweigungen der Pipeline.
Beispiele
In diesem Beispiel werden drei Phasen nacheinander ausgeführt. Die mittlere Phase führt zwei Aufträge parallel aus.
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 diesem Beispiel werden zwei Phasen parallel ausgeführt. Aus Platzgründen werden die Aufträge und Schritte weggelassen.
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
Siehe auch
Erfahren Sie mehr über Phasen, Bedingungenund Variablen.