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.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
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 zwischen Pipelineausführungen geändert werden.
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, um Ihre Anwendung in jeder Phase ihrer klassischen Releasepipeline bereitzustellen, können Variablen Ihnen helfen:
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 Variablen 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 Variablen 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. Diese Variablen bieten Ihnen Zugriff auf Details zum System, release, stage oder agent, in dem sie ausgeführt werden.
Mit Ausnahme von System.Debug sind Standardvariablen schreibgeschützt, und das System legt ihre Werte automatisch fest.
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 Variable 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 Variable in Ihren Skripts oder Aufgaben, um REST-APIs für andere Dienste wie Build- und Versionssteuerung 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 Pipeline Artefakte während der Bereitstellung einer Version herunterlädt. Die Pipeline löscht das Verzeichnis vor jeder Bereitstellung, falls 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 Pipeline während der Bereitstellung eines Releases Artefakte herunterlädt. Die Pipeline löscht das Verzeichnis vor jeder Bereitstellung, 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 Agenten, in dem die Pipeline Unterordner für jeden Build oder jedes Release erstellt. Identisch mit Agent.RootDirectory und Agent.WorkFolder.Beispiel: C:\agent\_work |
| System.Debug | Dies ist die einzige Systemvariable, die Benutzer festlegen können. Legen Sie diese Variable auf true fest, um die Release im Debug-Modus auszuführen, 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 ist 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 die Veröffentlichung geplant oder manuell ausgelöst wird. Beispiel: fabrikam\_app |
Versionsphasenvariablen
| Variablenname | BESCHREIBUNG |
|---|---|
| Release.Environments. {Phasenname}. 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 Name 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 Jobs, der ausgeführt wird, 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 Bereitstellung einer Version Artefakte herunterlädt. Das Verzeichnis wird vor jeder Bereitstellung gelöscht, wenn Artefakte auf den Agent heruntergeladen werden müssen. Es ist 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. Es ist 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. Es ist identisch mit Agent.RootDirectory und System.WorkFolder.Beispiel: C:\agent\_work |
| Agent.DeploymentGroupId | Die ID der Bereitstellungsgruppe, bei der der Agent registriert wird. Diese ID ist nur in Bereitstellungsgruppenaufträgen verfügbar. Beispiel: 1 |
Freigeben von Artefaktenvariablen
Verwenden Sie für jedes Artefakt, auf das Sie in einer Version verweisen, die folgenden Artefaktvariablen. Beachten Sie, dass nicht alle Variablen für jeden Artefakttyp gelten. In der folgenden Tabelle sind Standardartefaktevariablen aufgeführt und Beispiele für deren Werte basierend auf dem Artefakttyp. Wenn ein Beispiel leer ist, gibt es an, dass die Variable für diesen Artefakttyp nicht anwendbar ist.
Ersetzen Sie den {alias} Platzhalter durch den Wert, den Sie für den Artefaktquellenalias angeben, oder durch den Standardwert, der für die Release-Pipeline generiert wird.
| 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: $/fabrikamEinguss: fabrikamGithub: fabrikam/asp (main) |
| Release.Artifacts.{alias}.BuildNumber | Die Buildnummer oder der Commitbezeichner. Beispiele: Azure-Pipelines: 20170112.1Jenkins: 20170112.1TFVC: Changeset 3Einguss: 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: JenkinsAzure DevOps Services: TFVCEinguss: 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 Release-Pipelines mehrere Artefakte verwenden, können Sie ein Artefakt als primäres Artefakt festlegen. Azure Pipelines füllt dann die folgenden Variablen für das angegebene primäre Artefakt auf.
| Variablenname | Identisch mit |
|---|---|
| Build.DefinitionId | Release.Artifacts. {Primärer Artefaktalias}. DefinitionId |
| Build.DefinitionName | Release.Artifacts. {Primärer Artefaktalias}. DefinitionName |
| Build.BuildNumber | Release.Artifacts. {Primärer Artefaktalias}. BuildNumber |
| Build.BuildId | Release.Artifacts. {Primärer Artefaktalias}. BuildId |
| Build.BuildURI | Release.Artifacts. {Primärer Artefaktalias}. BuildURI |
| Build.SourceBranch | Release.Artifacts. {Primärer Artefaktalias}. SourceBranch |
| Build.SourceBranchName | Release.Artifacts. {Primärer Artefaktalias}. SourceBranchName |
| Build.SourceVersion | Release.Artifacts. {Primärer Artefaktalias}. SourceVersion |
| Build.Repository.Provider | Release.Artifacts. {Primärer Artefaktalias}. Repository.Provider |
| Build.RequestedForID | Release.Artifacts. {Primärer Artefaktalias}. RequestedForID |
| Build.RequestedFor | Release.Artifacts. {Primärer Artefaktalias}. RequestedFor |
| Build.Type | Release.Artifacts. {Primärer Artefaktalias}. Art |
| Build.PullRequest.TargetBranch | Release.Artifacts. {Primärer Artefaktalias}. PullRequest.TargetBranch |
| Build.PullRequest.TargetBranchName | Release.Artifacts. {Primärer Artefaktalias}. 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.
Verwenden Sie eine Standardvariable direkt als Eingabe für eine Aufgabe. Um z. B. Release.Artifacts.{Artifact alias}.DefinitionName als Argument an eine PowerShell-Aufgabe für ein Artefakt mit ASPNET4.CI als Alias zu übergeben, verwenden Sie $(Release.Artifacts.ASPNET4.CI.DefinitionName).
Wenn Sie eine Standardvariable in Ihrem Skript verwenden möchten, ersetzen Sie die . Standardvariablennamen durch _. 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. Der ursprüngliche Alias ASPNET4.CI wird durch ASPNET4_CI ersetzt.
Benutzerdefinierte Variablen
Sie können benutzerdefinierte Variablen in verschiedenen Bereichen definieren.
Variablengruppen: Verwenden Sie Variablengruppen, um Werte für alle Definitionen in einem Projekt freizugeben. Dieser Ansatz 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. Dieser Ansatz eignet sich ideal für Szenarien, in denen Sie einen konsistenten Wert über Phasen und Aufgaben hinweg benötigen, mit der Möglichkeit, ihn 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. Dieser Ansatz ist nützlich für Werte, die sich von Stufe zu Stufe 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.
Mithilfe von benutzerdefinierten Variablen auf Projekt-, Releasepipeline- und Phasenebene können Sie folgende Aktionen ausführen:
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 Variablen (geheim) werden sicher auf dem Server gespeichert, und die Benutzer können sie nach dem Speichern nicht sehen. Während der Bereitstellung entschlüsselt Azure Pipelines diese Werte, wenn Aufgaben darauf verweisen und sie über einen sicheren HTTPS-Kanal an den Agent übergeben.
Hinweis
Durch das Erstellen von benutzerdefinierten Variablen können Standardvariablen überschrieben werden. Wenn Sie beispielsweise eine benutzerdefinierte Pfadvariable für einen Windows-Agent definieren, überschreibt sie die Variable $env:Path und verhindert möglicherweise, dass PowerShell 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, fügen Sie den aktuellen Wert in eine Aufgabe ein als $(adminUserName).
Hinweis
Variablen aus unterschiedlichen Gruppen, die im selben Bereich mit einer Pipeline verknüpft sind (z. B. Job oder Stufe), können zu Konflikten und unvorhersehbaren Ergebnissen führen. Um dieses Problem zu vermeiden, stellen Sie sicher, dass 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.
In diesem Schritt werden die Protokolle geöffnet. Scrollen Sie nach unten, um die Werte anzuzeigen, die der Agent für diesen Auftrag verwendet.
Ausführen eines Releases im Debugmodus
Das Ausführen einer Version im Debugmodus kann Ihnen helfen, Probleme 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 in einer bestimmten Veröffentlichungsphase aktivieren.
Um den Debugmodus für die gesamte Version zu aktivieren, fügen Sie eine Variable
System.Debugmit dem Werttruezur Registerkarte "Variablen " der Releasepipeline hinzu.Um den Debugmodus für eine bestimmte Phase zu aktivieren, öffnen Sie das Dialogfeld " Phase konfigurieren " im Kontextmenü der Phase, und fügen Sie eine Variable
System.Debugmit dem Werttruezur Registerkarte "Variablen " 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 ein Fehler im Zusammenhang mit Azure Resource Manager-Dienstverbindungen auftritt, finden Sie im Abschnitt Fehlerbehebung bei Azure Resource Manager-Dienstverbindungen weitere Details.