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: 1GitHub: fabrikam/asp |
| Release.Artifacts.{alias}.DefinitionName | Der Name der Buildpipeline oder des Repositorys. Beispiele: Azure Pipelines: fabrikam-ciTFVC: $/fabrikamGit: fabrikamGitHub: fabrikam/asp (main) |
| Release.Artifacts.{alias}.BuildNumber | Die Buildnummer oder der Commitbezeichner. Beispiele: Azure Pipelines: 20170112.1Jenkins: 20170112.1TFVC: Changeset 3Git: 38629c964GitHub: 38629c964 |
| Release.Artifacts.{alias}.BuildId | Der Buildbezeichner. Beispiele: Azure Pipelines: 130Jenkins: 130GitHub: 38629c964d21fe405ef830b7d0220966b82c9e11 |
| Release.Artifacts.{alias}.BuildURI | Die URL für den Build. Beispiele: Azure Pipelines: vstfs://build-release/Build/130GitHub: 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: BuildJenkins: JenkinsTFVC: TFVCGit: GitGitHub: 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.
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.
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
-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:
- Windows-Agent (entweder mit einem Batch-Skriptaufgabe oder mit einem PowerShell-Skriptaufgabe)
- macOS- oder Linux-Agent (mit einem Shell-Skriptaufgabe)
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)
Festlegen der Variablen 
Festlegen der Variablen 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
Wählen Sie Pipelines>Releases und dann Ihre Releasepipeline aus.
Ö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.
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.
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.Debugmit dem Werttrueder 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.DebugVariablentrueeine Variable mit dem Namen und dem Wert hinzu.Alternativ können Sie eine Variablengruppe erstellen, die eine Variable namens
System.Debugmit dem Werttrueenthä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.