Freigeben über


Verwenden von Variablen in klassischen Releasepipelines

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

Verwenden von Variablen in klassischen Releasepipelines sind eine bequeme Möglichkeit, Daten in Ihrer Pipeline auszutauschen und zu transportieren. Jede Variable wird als Zeichenfolge gespeichert, und ihr Wert kann sich zwischen den Pipelineausführungen ändern.

Im Gegensatz zu Laufzeitparametern, die nur zur Vorlagenanalysezeit verfügbar sind, sind Variablen in klassischen Releasepipelinen während des gesamten Bereitstellungsprozesses zugänglich.

Wenn Sie Aufgaben einrichten, die Ihre Anwendung in jeder Phase der klassischen Releasepipeline bereitstellen sollen, helfen Variablen Ihnen bei Folgendem:

  • Vereinfachen der Anpassung: Definieren Sie eine generische Bereitstellungspipeline einmal, und passen Sie sie für die jeweiligen Phasen einfach an. Verwenden Sie beispielsweise eine Variable, um die Verbindungszeichenfolge einer Webbereitstellung darzustellen, und passen Sie ihren Wert nach Bedarf für jede Phase an. Diese werden als benutzerdefinierte Variablen bezeichnet.

  • Nutzen der kontextbezogenen Informationen: Greifen Sie auf Details zum Releasekontext zu, wie Phase, Artefakt oder Agent, der die Bereitstellung ausführt. Ihre Skripts benötigen z. B. den Buildspeicherort für den Download oder das Arbeitsverzeichnis des Agents, um temporäre Dateien zu erstellen. Diese werden als Standardvariablen bezeichnet.

Hinweis

Weitere Informationen zu YAML-Pipelines finden Sie unter Benutzerdefinierte Variablen und Vordefinierte Variablen.

Standardvariablen

Standardvariablen stellen wichtige Informationen zum Ausführungskontext für Ihre ausgeführten Aufgaben und Skripts bereit. Mit diesen Variablen können Sie auf Details zu System, Release, Phase oder Agent erhalten.

Mit Ausnahme von System.Debug sind Standardvariablen schreibgeschützt, und ihre Werte werden automatisch vom System festgelegt.

Einige der wichtigsten Variablen werden in den folgenden Tabellen beschrieben. Eine vollständige Liste finden Sie unter Anzeigen der aktuellen Werte aller Variablen.

Systemvariablen

Variablenname BESCHREIBUNG
System.TeamFoundationServerUri Die URL der Dienstverbindung in Azure Pipelines. Verwenden Sie diese in Ihren Skripts oder Aufgaben, um Azure Pipelines-REST-APIs aufzurufen.

Beispiel: https://fabrikam.vsrm.visualstudio.com/
System.TeamFoundationCollectionUri Die URL der Team Foundation-Sammlung oder von Azure Pipelines. Verwenden Sie diese in Ihren Skripts oder Aufgaben, um REST-APIs für andere Dienste (z. B. den Builddienst und die Versionskontrolle) aufzurufen.

Beispiel: https://dev.azure.com/fabrikam/
System.CollectionId Die ID der Sammlung, der dieser Build oder dieses Release angehört.

Beispiel: 6c6f3423-1c84-4625-995a-f7f143a1e43d
System.DefinitionId Die ID der Releasepipeline, der das aktuelle Release angehört.

Beispiel: 1
System.TeamProject Der Name des Projekts, dem dieser Build oder dieses Release angehört.

Beispiel: Fabrikam
System.TeamProjectId Die ID des Projekts, dem dieser Build oder dieses Release angehört.

Beispiel: 79f5c12e-3337-4151-be41-a268d2c73344
System.ArtifactsDirectory Das Verzeichnis, in das die Artefakte bei der Bereitstellung eines Releases heruntergeladen werden. Das Verzeichnis wird vor jeder Bereitstellung gelöscht, wenn Artefakte auf den Agent heruntergeladen werden müssen. Identisch mit „Agent.ReleaseDirectory“ und „System.DefaultWorkingDirectory“.

Beispiel: C:\agent\_work\r1\a
System.DefaultWorkingDirectory Das Verzeichnis, in das die Artefakte bei der Bereitstellung eines Releases heruntergeladen werden. Das Verzeichnis wird vor jeder Bereitstellung gelöscht, wenn Artefakte auf den Agent heruntergeladen werden müssen. Identisch mit „Agent.ReleaseDirectory“ und „System.ArtifactsDirectory“.

Beispiel: C:\agent\_work\r1\a
System.WorkFolder Das Arbeitsverzeichnis für diesen Agent, in dem für jeden Build oder jedes Release Unterordner erstellt werden. Identisch mit „Agent.RootDirectory“ und „Agent.WorkFolder“.

Beispiel: C:\agent\_work
System.Debug Dies ist die einzige Systemvariable, die von den Benutzer*innen festgelegt werden kann. Bei einer Festlegung auf TRUE wird das Release im Debugmodus ausgeführt, um die Fehlersuche zu unterstützen.

Beispiel: true

Releasevariablen

Variablenname BESCHREIBUNG
Release.AttemptNumber Gibt an, wie oft dieses Release in dieser Stage bereitgestellt wird.

Beispiel: 1
Release.DefinitionEnvironmentId Die ID der Stage in der entsprechenden Releasepipeline.

Beispiel: 1
Release.DefinitionId Die ID der Releasepipeline, der das aktuelle Release angehört.

Beispiel: 1
Release.DefinitionName Der Name der Releasepipeline, zu der das aktuelle Release gehört.

Beispiel: fabrikam-cd
Release.Deployment.RequestedFor Der Anzeigename der Identität, die die derzeit durchgeführte Bereitstellung ausgelöst (gestartet) hat.

Beispiel: Mateo Escobedo
Release.Deployment.RequestedForEmail Die E-Mail-Adresse der Identität, die die derzeit durchgeführte Bereitstellung ausgelöst (gestartet) hat.

Beispiel: mateo@fabrikam.com
Release.Deployment.RequestedForId Die ID der Identität, die die derzeit durchgeführte Bereitstellung ausgelöst (gestartet) hat.

Beispiel: 2f435d07-769f-4e46-849d-10d1ab9ba6ab
Release.DeploymentID Die ID der Bereitstellung. Eindeutig pro Auftrag.

Beispiel: 254
Release.DeployPhaseID Die ID der Phase, in der die Bereitstellung durchgeführt wird.

Beispiel: 127
Release.EnvironmentId Die ID der Stage-Instanz in einem Release, für das die Bereitstellung derzeit durchgeführt wird.

Beispiel: 276
Release.EnvironmentName Der Name der Stage, für die derzeit die Bereitstellung durchgeführt wird.

Beispiel: Dev
Release.EnvironmentUri Der URI der Stage-Instanz in einem Release, für das die Bereitstellung derzeit durchgeführt wird.

Beispiel: vstfs://ReleaseManagement/Environment/276
Release.Environments.{stage-name}.status Der Bereitstellungsstatus der Stage.

Beispiel: InProgress
Release.PrimaryArtifactSourceAlias Der Alias der primären Artefaktquelle.

Beispiel: fabrikam\_web
Release.Reason Der Grund für die Bereitstellung. Diese Werte werden unterstützt:
ContinuousIntegration: Das Release wurde im Continuous Deployment-Modus gestartet, nachdem ein Build abgeschlossen wurde.
Manual: Das Release wurde manuell gestartet.
None: Der Bereitstellungsgrund wurde nicht angegeben.
Schedule: Das Release wurde über einen Zeitplan gestartet.
Release.ReleaseDescription Die Textbeschreibung, die zum Zeitpunkt der Veröffentlichung bereitgestellt wurde.

Beispiel: Critical security patch
Release.ReleaseId Der Bezeichner des aktuellen Releasedatensatzes.

Beispiel: 118
Release.ReleaseName Der Name des aktuellen Releases.

Beispiel: Release-47
Release.ReleaseUri Der URI des aktuellen Releases.

Beispiel: vstfs://ReleaseManagement/Release/118
Release.ReleaseWebURL Die URL für dieses Release.

Beispiel: https://dev.azure.com/fabrikam/f3325c6c/_release?releaseId=392&_a=release-summary
Release.RequestedFor Der Anzeigename der Identität, die das Release ausgelöst hat.

Beispiel: Mateo Escobedo
Release.RequestedForEmail Die E-Mail-Adresse der Identität, die das Release ausgelöst hat.

Beispiel: mateo@fabrikam.com
Release.RequestedForId Die ID der Identität, die das Release ausgelöst hat.

Beispiel: 2f435d07-769f-4e46-849d-10d1ab9ba6ab
Release.SkipArtifactsDownload Boolescher Wert, der angibt, ob das Herunterladen von Artefakten auf den Agent übersprungen werden soll.

Beispiel: FALSE
Release.TriggeringArtifact.Alias Der Alias des Artefakts, das das Release ausgelöst hat. Dieser Wert ist leer, wenn das Release geplant oder manuell ausgelöst wurde.

Beispiel: fabrikam\_app

Versionsphasenvariablen

Variablenname BESCHREIBUNG
Release.Environments.{stage name}.Status Der Bereitstellungsstatus dieses Releases innerhalb einer angegebenen Stage.

Beispiel: NotStarted

Agent-Variablen

Variablenname BESCHREIBUNG
Agent.Name Der Name des Agents, wie er im Agentpool registriert ist. Dieser unterscheidet sich wahrscheinlich vom Computernamen.

Beispiel: fabrikam-agent
Agent.MachineName Der Name des Computers, auf dem der Agent konfiguriert ist.

Beispiel: fabrikam-agent
Agent.Version Die Version der Agentsoftware.

Beispiel: 2.109.1
Agent.JobName Der Name des ausgeführten Auftrags, z. B. „Release“ oder „Build“.

Beispiel: Release
Agent.HomeDirectory Der Ordner, in dem der Agent installiert ist. Dieser Ordner enthält den Code und die Ressourcen für den Agent.

Beispiel: C:\agent
Agent.ReleaseDirectory Das Verzeichnis, in das die Artefakte bei der Bereitstellung eines Releases heruntergeladen werden. Das Verzeichnis wird vor jeder Bereitstellung gelöscht, wenn Artefakte auf den Agent heruntergeladen werden müssen. Identisch mit „System.ArtifactsDirectory“ und „System.DefaultWorkingDirectory“.

Beispiel: C:\agent\_work\r1\a
Agent.RootDirectory Das Arbeitsverzeichnis für diesen Agent, in dem für jeden Build oder jedes Release Unterordner erstellt werden. Identisch mit „Agent.WorkFolder“ und „System.WorkFolder“.

Beispiel: C:\agent\_work
Agent.WorkFolder Das Arbeitsverzeichnis für diesen Agent, in dem für jeden Build oder jedes Release Unterordner erstellt werden. Identisch mit „Agent.RootDirectory“ und „System.WorkFolder“.

Beispiel: C:\agent\_work
Agent.DeploymentGroupId Die ID der Bereitstellungsgruppe, bei der der Agent registriert ist. Nur in Bereitstellungsgruppenaufträgen verfügbar.

Beispiel: 1

Releaseartefaktvariablen

Für jedes Artefakt, auf das in einem Release verwiesen wird, können Sie die folgenden Artefaktvariablen verwenden. Beachten Sie, dass nicht alle Variablen für jeden Artefakttyp gelten. In der folgenden Tabelle finden Sie eine Liste der standardmäßigen Artefaktvariablen und Beispiele für deren Werte, die sie je nach Artefakttyp aufweisen. Wenn ein Beispiel leer ist, bedeutet dies, dass die Variable für diesen Artefakttyp nicht anwendbar ist.

Ersetzen Sie den Platzhalter {alias} durch den für den Artefaktquellalias angegebenen Wert oder durch den für die Releasepipeline generierten Standardwert.

Variablenname BESCHREIBUNG
Release.Artifacts.{alias}.DefinitionId Der Bezeichner der Buildpipeline oder des Repositorys. Beispiele:

Azure Pipelines: 1
GitHub: fabrikam/asp
Release.Artifacts.{alias}.DefinitionName Der Name der Buildpipeline oder des Repositorys. Beispiele:

Azure Pipelines: fabrikam-ci
TFVC: $/fabrikam
Git: fabrikam
GitHub: fabrikam/asp (main)
Release.Artifacts.{alias}.BuildNumber Die Buildnummer oder der Commitbezeichner. Beispiele:

Azure Pipelines: 20170112.1
Jenkins: 20170112.1
TFVC: Changeset 3
Git: 38629c964
GitHub: 38629c964
Release.Artifacts.{alias}.BuildId Der Buildbezeichner. Beispiele:

Azure Pipelines: 130
Jenkins: 130
GitHub: 38629c964d21fe405ef830b7d0220966b82c9e11
Release.Artifacts.{alias}.BuildURI Die URL für den Build. Beispiele:

Azure Pipelines: vstfs://build-release/Build/130
GitHub: https://github.com/fabrikam/asp
Release.Artifacts.{alias}.SourceBranch Der vollständige Pfad und Name der Verzweigung, aus dem die Quelle erstellt wurde. Beispiele:

Azure Pipelines: refs/heads/main
Release.Artifacts.{alias}.SourceBranchName Nur der Name der Verzweigung, aus dem die Quelle erstellt wurde. Beispiele:

Azure Pipelines: main
Release.Artifacts.{alias}.SourceVersion Der erstellte Commit. Beispiele:

Azure Pipelines: bc0044458ba1d9298cdc649cb5dcf013180706f7
Release.Artifacts.{alias}.Repository.Provider Der Typ des Repositorys, aus dem die Quelle erstellt wurde. Beispiele:

Azure Pipelines: Git
Release.Artifacts.{alias}.RequestedForID Der Bezeichner des Kontos, das den Build ausgelöst hat. Beispiele:

Azure Pipelines: 2f435d07-769f-4e46-849d-10d1ab9ba6ab
Release.Artifacts.{alias}.RequestedFor Der Name des Kontos, das den Build angefordert hat. Beispiele:

Azure Pipelines: Mateo Escobedo
Release.Artifacts.{alias}.Type Der Typ der Artefaktquelle, z. B. „Build“. Beispiele:

Azure Pipelines: Build
Jenkins: Jenkins
TFVC: TFVC
Git: Git
GitHub: GitHub
Release.Artifacts.{alias}.PullRequest.TargetBranch Der vollständige Pfad und Name des Branchs, der das Ziel von einem Pull Request ist. Diese Variable wird nur initialisiert, wenn das Release durch einen Pull Request-Flow ausgelöst wird. Beispiele:

Azure Pipelines: refs/heads/main
Release.Artifacts.{alias}.PullRequest.TargetBranchName Nur der Name des Branchs, der das Ziel von einem Pull Request ist. Diese Variable wird nur initialisiert, wenn das Release durch einen Pull Request-Flow ausgelöst wird. Beispiele:

Azure Pipelines: main

Primäre Artefaktvariablen

Wenn Sie in klassischen Releasepipelinen mehrere Artefakte verwenden, können Sie eines als primäres Artefakt festlegen. Für das angegebene primäre Artefakt füllt Azure Pipelines die folgenden Variablen auf.

Variablenname Identisch mit
Build.DefinitionId Release.Artifacts.{Primary artifact alias}.DefinitionId
Build.DefinitionName Release.Artifacts.{Primary artifact alias}.DefinitionName
Build.BuildNumber Release.Artifacts.{Primary artifact alias}.BuildNumber
Build.BuildId Release.Artifacts.{Primary artifact alias}.BuildId
Build.BuildURI Release.Artifacts.{Primary artifact alias}.BuildURI
Build.SourceBranch Release.Artifacts.{Primary artifact alias}.SourceBranch
Build.SourceBranchName Release.Artifacts.{Primary artifact alias}.SourceBranchName
Build.SourceVersion Release.Artifacts.{Primary artifact alias}.SourceVersion
Build.Repository.Provider Release.Artifacts.{Primary artifact alias}.Repository.Provider
Build.RequestedForID Release.Artifacts.{Primary artifact alias}.RequestedForID
Build.RequestedFor Release.Artifacts.{Primary artifact alias}.RequestedFor
Build.Type Release.Artifacts.{Primary artifact alias}.Type
Build.PullRequest.TargetBranch Release.Artifacts.{Primary artifact alias}.PullRequest.TargetBranch
Build.PullRequest.TargetBranchName Release.Artifacts.{Primary artifact alias}.PullRequest.TargetBranchName

Verwenden von Standardvariablen

Sie können die Standardvariablen auf zwei Arten verwenden: als Parameter für Aufgaben in einer Releasepipeline oder in Ihren Skripts.

Sie können eine Standardvariable direkt als Eingabe für eine Aufgabe verwenden. Um beispielsweise Release.Artifacts.{Artifact alias}.DefinitionName als Argument an eine PowerShell-Aufgabe für ein Artefakt mit ASPNET4.CI als Alias zu übergeben, würden Sie $(Release.Artifacts.ASPNET4.CI.DefinitionName) verwenden.

Screenshot, der zeigt, wie eine Standardvariable als Argument verwendet wird.

Um eine Standardvariable in Ihrem Skript zu verwenden, müssen Sie zunächst den . im Namen der Standardvariable durch _ ersetzen. Um beispielsweise den Wert von Release.Artifacts.{Artifact alias}.DefinitionName für ein Artefakt mit ASPNET4.CI als Alias in einem PowerShell-Skript zu drucken, verwenden Sie $env:RELEASE_ARTIFACTS_ASPNET4_CI_DEFINITIONNAME. Beachten Sie, dass der ursprüngliche Alias ASPNET4.CI mit ASPNET4_CI ersetzt wird.

Screenshot, der zeigt, wie eine Standardvariable in einem Inline-PowerShell-Skript verwendet wird.

Benutzerdefinierte Variablen

Benutzerdefinierte Variablen können in verschiedenen Bereichen definiert werden.

  • Variablengruppen: Verwenden Sie Variablengruppen, um Werte für alle Definitionen in einem Projekt freizugeben. Dies ist nützlich, wenn Sie dieselben Werte innerhalb von Definitionen, Phasen und Vorgängen innerhalb eines Projekts verwenden und von einem einzigen Speicherort aus verwalten möchten. Sie definieren und verwalten Variablengruppen unter Pipelines>Bibliothek.

  • Releasepipelinevariablen: Verwenden Sie Releasepipelinevariablen, um Werte in allen Phasen einer Releasepipeline freizugeben. Dies ist ideal für Szenarien, in denen Sie einen konsistenten Wert über Phasen und Aufgaben hinweg benötigen, mit der Möglichkeit, sie von einem einzigen Ort aus zu aktualisieren. Sie definieren und verwalten diese Variablen auf der Registerkarte Variablen in der Releasepipeline. Legen Sie beim Hinzufügen einer Variable auf der Seite „Pipelinevariablen“ die Dropdownliste Umfang auf Release fest.

  • Phasenvariablen: Verwenden Sie Phasenvariablen, um Werte innerhalb einer bestimmten Phase einer Releasepipeline freizugeben. Dies ist nützlich für Werte, die sich von Phase zu Phase unterscheiden, aber für alle Aufgaben innerhalb einer Phase konsistent sind. Sie definieren und verwalten diese Variablen auf der Registerkarte Variablen in der Releasepipeline. Legen Sie auf der Seite „Pipelinevariablen“ die Dropdownliste Umfang auf die entsprechende Umgebung fest, wenn Sie eine Variable hinzufügen.

Die Verwendung benutzerdefinierter Variablen auf der Projekt-, Releasepipeline- und Phasenebene ermöglicht Folgendes:

  • Das Duplizieren von Werten wird vermieden, wodurch es einfacher ist, alle Vorkommen mit einer einzelnen Änderung zu aktualisieren.

  • Schützen Sie vertrauliche Werte, indem Sie verhindern, dass sie von Benutzern angezeigt oder geändert werden. Um eine Variable als sicher (geheim) zu markieren, wählen Sie das Schloss-Symbol neben der Variablen aus.

    Wichtig

    Die Werte der ausgeblendeten (geheimen) Variablen werden sicher auf dem Server gespeichert und können von Benutzern nach dem Speichern nicht mehr angezeigt werden. Während einer Bereitstellung entschlüsselt Azure Pipelines diese Werte (sofern sie von den Aufgaben referenziert werden) und leitet sie über einen sicheren HTTPS-Kanal an den Agent weiter.

Hinweis

Durch das Erstellen von benutzerdefinierten Variablen können Standardvariablen überschrieben werden. Wenn Sie beispielsweise eine benutzerdefinierte Pfadvariable für einen Windows-Agent definieren, wird die Variable $env:Path überschrieben, wodurch PowerShell möglicherweise nicht ordnungsgemäß ausgeführt wird.

Verwenden von benutzerdefinierten Variablen

Um benutzerdefinierte Variablen in Ihren Aufgaben zu verwenden, schließen Sie den Variablennamen einfach in Klammern ein und stellen ihm ein $-Zeichen voran. Wenn Sie z. B. über eine Variable mit dem Namen adminUserName verfügen, können Sie ihren aktuellen Wert in eine Aufgabe als $(adminUserName) einfügen.

Hinweis

Variablen aus unterschiedlichen Gruppen, die mit einer Pipeline in demselben Bereich (z. B. Auftrag oder Phase) verknüpft sind, können Konflikte verursachen, was zu unvorhersehbaren Ergebnissen führt. Um dies zu vermeiden, stellen Sie sicher, dass die Variablen in allen Variablengruppen eindeutige Namen haben.

Definieren und Ändern Ihrer Variablen in einem Skript

Wenn Sie eine Variable über ein Skript definieren oder ändern möchten, verwenden Sie den Protokollierungsbefehl task.setvariable. Der aktualisierte Variablenwert ist auf den derzeit ausgeführten Auftrag beschränkt und wird nicht über Aufträge oder Phasen hinweg weitergegeben. Beachten Sie, dass Variablennamen in Großbuchstaben umgewandelt werden, wobei „.“ und „ ‚ durch ‘_“ ersetzt werden.

Beispielsweise wird Agent.WorkFolder zu AGENT_WORKFOLDER.

  • Unter Windows erfolgt der Zugriff auf diese Variable als %AGENT_WORKFOLDER% oder $env:AGENT_WORKFOLDER.
  • Unter Linux und macOS verwenden Sie $AGENT_WORKFOLDER.

Tipp

Ein Skript kann über folgende Agents ausgeführt werden:

Batchskript

Festlegen der Variablen sauce und secret.Sauce

@echo ##vso[task.setvariable variable=sauce]crushed tomatoes
@echo ##vso[task.setvariable variable=secret.Sauce;issecret=true]crushed tomatoes with garlic

Lesen der Variablen

Argumente

"$(sauce)" "$(secret.Sauce)"

Skript

@echo off
set sauceArgument=%~1
set secretSauceArgument=%~2
@echo No problem reading %sauceArgument% or %SAUCE%
@echo But I cannot read %SECRET_SAUCE%
@echo But I can read %secretSauceArgument% (but the log is redacted so I do not spoil the secret)

Konsolenausgabe nach dem Lesen der Variablen:

No problem reading crushed tomatoes or crushed tomatoes
But I cannot read 
But I can read ******** (but the log is redacted so I do not spoil the secret)

Anzeigen der aktuellen Werte aller Variablen

  1. Wählen Sie Pipelines>Releases und dann Ihre Releasepipeline aus.

  2. Öffnen Sie die Zusammenfassungsansicht für Ihre Version, und wählen Sie die gewünschte Phase aus. Wählen Sie in der Liste der Schritte Auftrag initialisieren aus.

    Screenshot mit dem Schritt zum Initialisieren des Auftrags.

  3. Dadurch werden die Protokolle für diesen Schritt geöffnet. Scrollen Sie nach unten, um die vom Agent für diesen Auftrag verwendeten Werte anzuzeigen.

    Screenshot mit den vom Agent verwendeten Variablen.

Ausführen eines Releases im Debugmodus

Das Ausführen einer Version im Debugmodus kann Ihnen helfen, Probleme oder Fehler zu diagnostizieren und zu beheben, indem zusätzliche Informationen während der Releaseausführung angezeigt werden. Sie können den Debugmodus für die gesamte Version oder nur für die Aufgaben innerhalb einer bestimmten Veröffentlichungsphase aktivieren.

  • Um den Debugmodus für ein gesamtes Release zu aktivieren, fügen Sie eine Variable namens System.Debug mit dem Wert true der Registerkarte Variablen der Releasepipeline hinzu.

  • Um den Debugmodus für eine bestimmte Phase zu starten, öffnen Sie das Dialogfeld Phase konfigurieren aus dem Kontextmenü der Phase, und fügen Sie auf der Registerkarte System.DebugVariablentrue eine Variable mit dem Namen und dem Wert hinzu.

  • Alternativ können Sie eine Variablengruppe erstellen, die eine Variable namens System.Debug mit dem Wert true enthält, und diese Variablengruppe mit der Releasepipeline verknüpfen.

Tipp

Wenn Sie eine Fehlermeldung im Zusammenhang mit einer Azure ARM-Dienstverbindung erhalten, erhalten Sie unter Problembehandlung für ARM-Dienstverbindungen weitere Informationen.