Azure DevOps-Variablen für die Automatisierung freischalten

Wenn Sie eine Azure DevOps-Pipeline als Lösung für eine CI/CD-Pipeline erstellt haben, sind Sie sicherlich auf Situationen gestoßen, die das dynamische Verwalten von Konfigurationswerten in Builds und Veröffentlichungen erfordern. Ob es darum geht, eine Build-Version an ein PowerShell-Skript zu übergeben, dynamische Parameter an Build-Aufgaben zu übergeben oder Zeichenfolgen in Builds und Veröffentlichungen zu verwenden – Sie benötigen Variablen.

Wenn Sie sich jemals Fragen gestellt haben wie:

• Wie verwende ich Azure DevOps Build-Pipeline-Variablen in einem PowerShell-Skript?
• Wie teile ich Variablen über Builds und Veröffentlichungen hinweg?
• Wie unterscheiden sich vordefinierte, benutzerdefinierte und geheime Variablen?
• Wie funktionieren Variablengruppen?

…dann haben Sie Glück! In diesem Artikel werden wir jede dieser Fragen und mehr beantworten.

Am Ende dieses Artikels werden Sie verstehen, wie Azure DevOps Build-Variablen in Azure Pipelines funktionieren!

Was sind Azure DevOps Pipeline-Variablen?

Bevor wir uns mit den Einzelheiten der Variablen befassen, was sind sie und wie helfen sie Ihnen dabei, effiziente Build- und Veröffentlichungspipelines zu erstellen und zu automatisieren?

Variablen ermöglichen es Ihnen, Datenfragmente in verschiedene Teile Ihrer Pipelines zu übergeben. Variablen eignen sich hervorragend zum Speichern von Texten und Zahlen, die sich im Ablauf einer Pipeline ändern können. In einer Pipeline können Sie Variablen fast überall setzen und lesen, anstatt Werte in Skripten und YAML-Definitionen fest zu codieren.

Hinweis: Dieser Artikel konzentriert sich ausschließlich auf YAML-Pipelines. Wir werden keine Informationen zu Legacy-Classic-Pipelines abdecken. Außerdem werden Sie mit wenigen Ausnahmen nicht lernen, wie Sie über die Web-Benutzeroberfläche mit Variablen arbeiten. Wir halten uns strikt an YAML.

Variablen werden zur Laufzeit referenziert und einige werden definiert (siehe benutzerdefinierte Variablen). Wenn eine Pipeline einen Job initiiert, verwalten verschiedene Prozesse diese Variablen und übergeben ihre Werte an andere Teile des Systems. Dieses System ermöglicht das dynamische Ausführen von Pipelineseiten, ohne sich jedes Mal um Änderungen an Build-Definitionen und Skripten kümmern zu müssen.

Machen Sie sich keine Sorgen, wenn Sie das Konzept von Variablen zu diesem Zeitpunkt noch nicht verstehen. Der Rest dieses Artikels wird Ihnen alles beibringen, was Sie wissen müssen.

Variable Umgebungen

Bevor wir uns mit den Variablen selbst befassen, ist es zunächst wichtig, die Azure-Pipeline-Variable-Umgebungen zu erläutern. Sie werden im Laufe des Artikels verschiedene Verweise auf diesen Begriff sehen.

In einer Pipeline gibt es zwei informell als Umgebungen bezeichnete Bereiche, in denen Sie mit Variablen interagieren können. Sie können entweder mit Variablen innerhalb einer YAML-Build-Definition arbeiten, die als Umgebung der Pipeline bezeichnet wird, oder innerhalb eines über eine Aufgabe ausgeführten Skripts, das als Umgebung des Skripts bezeichnet wird.

Die Pipeline-Umgebung

Wenn Sie Build-Variablen in einer YAML-Build-Definition definieren oder lesen, wird dies als Pipeline-Umgebung bezeichnet. Im folgenden Beispiel sehen Sie den Abschnitt variables, der in einer YAML-Build-Definition definiert ist und eine Variable namens foo auf bar setzt. In diesem Kontext wird die Variable innerhalb der Pipeline-Umgebung definiert

variables:
  foo: 'bar'

Die Skript-Umgebung

Sie können auch mit Variablen arbeiten, die im YAML-Code oder in Skripten definiert sind. Wenn Sie noch kein vorhandenes Skript haben, können Sie Variablen in der YAML-Definition wie unten gezeigt definieren und lesen. Sie lernen später die Syntax, wie Sie mit diesen Variablen in diesem Kontext arbeiten können.

steps:
 - bash: ## Hier Variablen setzen und abrufen

Sie könnten alternativ in der Skript-Umgebung bleiben, indem Sie diese gleiche Syntax in ein Bash-Skript einfügen und es ausführen. Dies ist das gleiche allgemeine Konzept.

Umgebungsvariablen

In der Skript-Umgebung werden Pipeline-Variablen durch Erstellen einer Umgebungsvariable verfügbar gemacht. Diese Umgebungsvariablen können dann über die üblichen Methoden der gewählten Programmiersprache abgerufen werden.

Pipeline-Variablen, die als Umgebungsvariablen verfügbar gemacht werden, werden immer in Großbuchstaben geschrieben und Punkte durch Unterstriche ersetzt. Im folgenden Beispiel sehen Sie, wie jede Skriptsprache auf die foo-Pipeline-Variable zugreifen kann.

variables:
  foo: 'bar'

• Batch – %FOO%
• PowerShell – $env:FOO
• Bash-Skript – $FOO

Pipeline „Ausführungsphasen“

Wenn eine Pipeline „ausgeführt“ wird, wird sie nicht einfach nur „ausgeführt“. Wie die Stufen, die sie enthält, durchläuft eine Pipeline auch verschiedene Phasen während der Ausführung. Aufgrund des Fehlens eines offiziellen Begriffs in der Microsoft-Dokumentation bezeichne ich dies als „Ausführungsphasen“.

Wenn eine Pipeline ausgelöst wird, durchläuft sie drei grobe Phasen – Warteschlange, Kompilierung und Ausführung. Es ist wichtig, diese Kontexte zu verstehen, da Sie in den Microsoft-Dokumenten Verweise auf diese Begriffe finden werden.

Warteschlangenzeit

Die erste Phase, die eine Pipeline durchläuft, wenn sie in der Warteschlange steht. In dieser Phase hat die Pipeline noch nicht begonnen, steht jedoch in der Warteschlange und ist bereit loszulegen, wenn der Agent verfügbar ist. Bei der Definition von Variablen können Sie diese zur Warteschlangenzeit verfügbar machen, indem Sie sie nicht in der YAML-Datei definieren.

Sie können Variablen zur Warteschlangenzeit definieren, wenn die Pipeline zunächst in die Warteschlange gestellt wird, wie unten gezeigt. Wenn diese Variable hinzugefügt wird, wird sie dann als globale Variable in der Pipeline verfügbar und kann durch dieselbe Variablenbezeichnung in der YAML-Datei überschrieben werden.

Kompilierung

Schließlich, wenn eine Pipeline eine YAML-Datei verarbeitet und zu den Schritten gelangt, die eine Skriptausführung erfordern, befindet sich die Pipeline in der „Kompilierungsphase“. In diesem Kontext führt der Agent den im Skriptschritt definierten Code aus.

Ausführungszeit

Die nächste Phase ist die Laufzeit. Dies ist die Phase, in der die YAML-Datei verarbeitet wird. Während dieser Phase werden jede Stufe, jeder Job und jeder Schritt verarbeitet, aber nicht Skripte ausgeführt.

Variablenerweiterung

Ein weiteres wichtiges Thema, das verstanden werden muss, ist die Variablenerweiterung. Variablenerweiterung bedeutet im einfachsten Sinne, dass die Variable einen statischen Wert zurückgibt. Die Variable erweitert sich, um den Wert preiszugeben, den sie enthält. Dies geschieht automatisch, wenn Sie eine Variable lesen, aber diese Erweiterung kann zu verschiedenen Zeitpunkten während eines Pipeline-Durchlaufs erfolgen, was zu Verwirrung führen kann.

Dieses Konzept der Variablenerweiterung und der Kompilierungs- vs. Laufzeit wird häufig auftauchen, wenn Sie die Syntax von Variablen verstehen wollen.

Wie Sie oben gelernt haben, durchläuft die Pipeline verschiedene „Phasen“ während ihrer Ausführung. Sie müssen sich höchstwahrscheinlich mit diesen Phasen befassen, wenn Sie Probleme mit der Variablenerweiterung beheben wollen.

Sie können unten ein Beispiel sehen. Das Konzept dieser „Phasen“ ist eng mit Variablenumgebungen verbunden.

steps:
  # Legt FOO im Skript und den folgenden auf "some value" fest
  - bash: |
      FOO="runtime value"
      echo "##vso[task.setvariable variable=FOO]$FOO"

  # Verwendet die Syntax $() zur "Kompilierungszeit", die Pipeline erweitert die Variable
  - bash: |
      echo "$(FOO)"

  # Verwendet eine Umgebungsvariable im Skriptkontext zur "Laufzeit", bash erweitert die Variable
  - bash: |
      echo "$FOO"

Variablen werden einmal erweitert, wenn der Pipeline-Lauf gestartet wird, und dann zu Beginn jedes Schritts erneut. Im Folgenden sehen Sie ein einfaches Beispiel für dieses Verhalten.

jobs:
- job: build
  variables:
  - foo: bar 
  steps:
    - bash: |
        echo $(foo)            # This will be bar
        echo '##vso[task.setvariable variable=foo]baz'
        echo $(foo)            # This will also be bar, $(foo) expands before the step
    - bash: echo $(foo)        # Dies wird baz sein. Die Variable wird kurz vor dem Schritt erweitert

Variable Syntax

Wie Sie gelernt haben, können Sie Variablen in zwei „Umgebungen“ – der Pipeline- und der Skriptumgebung – festlegen oder lesen. In jeder Umgebung unterscheidet sich die Art und Weise, wie Sie auf Variablen verweisen, etwas. Es gibt einige Nuancen, auf die Sie achten müssen.

Pipeline-Variablen

Pipeline-Variablen werden in den YAML-Build-Definitionen referenziert und können über drei verschiedene Syntaxmethoden – Makro, Vorlagenausdruck und Laufzeitausdruck – referenziert werden.

Makro-Syntax

Die häufigste Syntax, die Sie finden werden, ist die Makro-Syntax. Die Makro-Syntax bezieht sich auf einen Wert für eine Variable in Form von $(foo). Die Klammern stellen einen Ausdruck dar, der zur Laufzeit ausgewertet wird.

Wenn Azure Pipelines eine als Makro-Ausdruck definierte Variable verarbeitet, ersetzt es den Ausdruck durch den Inhalt der Variable. Bei der Definition von Variablen mit Makro-Syntax folgen sie dem Muster <Variablenname>: $(<Variablenwert>) z.B. foo: $(bar).

Wenn Sie versuchen, auf eine Variable mit Makro-Syntax zu verweisen und kein Wert vorhanden ist, existiert die Variable einfach nicht. Dieses Verhalten unterscheidet sich etwas zwischen den Syntaxtypen.

Vorlagenausdruck-Syntax

Eine andere Art der Variablensyntax wird als Template-Ausdruck bezeichnet. Die Definition von Pipeline-Variablen erfolgt in der Form von ${{ variables.foo }} : ${{ variables.bar }}. Wie du sehen kannst, ist dies etwas ausführlicher als die Makro-Syntax.

Der Template-Ausdruckssyntax hat auch eine zusätzliche Funktion. Mit dieser Syntax kannst du auch Template-Parameter erweitern. Wenn auf eine Variable verwiesen wird, die mit der Template-Ausdruckssyntax definiert wurde, gibt die Pipeline einen leeren String zurück, im Gegensatz zu einem Nullwert bei der Makro-Syntax.

Template-Ausdrucksvariablen werden zur Kompilierzeit verarbeitet und dann (falls definiert) zur Laufzeit überschrieben.

Syntax für Laufzeitausdrücke

Wie der Name schon sagt, werden vorgeschlagene Laufzeitausdrucksvariablen nur zur Laufzeit erweitert. Diese Art von Variablen werden im Format $[variables.foo] dargestellt. Ähnlich wie bei Variablen mit Template-Ausdruckssyntax geben auch diese Variablen einen leeren String zurück, wenn sie nicht ersetzt werden.

Wie bei der Makro-Syntax erfordert auch die Syntax für Laufzeitausdrücke den Variablennamen auf der linken Seite der Definition, z. B. foo: $[variables.bar].

Skriptvariablen

Die Arbeit mit Variablen innerhalb von Skripten unterscheidet sich etwas von Pipeline-Variablen. Die Definition und Verwendung von Pipeline-Variablen in Aufgabenskripten kann auf zwei Arten erfolgen: mit Logging-Befehlssyntax oder Umgebungsvariablen.

Logging-Befehle

Eine Möglichkeit, Pipeline-Variablen in Skripten zu definieren und zu referenzieren, besteht darin, die Syntax für Logging-Befehle zu verwenden. Diese Syntax ist etwas umständlich, aber Sie werden feststellen, dass sie in bestimmten Situationen notwendig ist. Variablen, die auf diese Weise definiert werden, müssen als Zeichenkette im Skript definiert werden.

Die Definition einer Variablen namens foo mit einem Wert von bar unter Verwendung der Syntax für Logging-Befehle würde wie folgt aussehen.

"##vso[task.setvariable variable=foo;]bar"

I could not find a way to get the value of variables using logging commands. If this exists, let me know!

Umgekehrte Tags

Wenn Pipeline-Variablen in Skripten in Umgebungsvariablen umgewandelt werden, werden die Variablennamen geringfügig geändert. Sie werden feststellen, dass Variablennamen in Großbuchstaben umgewandelt werden und Punkte in Unterstriche umgewandelt werden. Viele vordefinierte oder Systemvariablen enthalten Punkte.

Zum Beispiel, wenn eine Pipeline-Variable namens [foo.bar](<http://foo.bar>) definiert wurde, würden Sie auf diese Variable über die natürliche Umgebungsvariablenreferenzmethode des Skripts zugreifen, wie z.B. $env:FOO_BAR in PowerShell oder $FOO_BAR in Bash.

Wir haben weitere Informationen zu Umgebungsvariablen im Abschnitt „Skriptumgebung“ oben behandelt.

Variablenscope

A pipeline has various stages, tasks and jobs running. Many areas have predefined variable scopes. A scope is namespace where when a variable is defined, its value can be referenced.

Es gibt im Wesentlichen drei verschiedene Variablenscopes in einer Hierarchie. Sie werden auf folgenden Ebenen definiert:

• auf der obersten Ebene, wodurch Variablen für alle Jobs in der Pipeline verfügbar werden
• auf der Stufenebene, wodurch Variablen für eine bestimmte Stufe verfügbar werden
• auf der Jobebene, wodurch Variablen für einen bestimmten Job verfügbar werden

Variablen, die auf „niedrigeren“ Ebenen definiert sind, wie z.B. ein Job, überschreiben die gleiche Variable, die auf der Stufen- und Wurzelebene definiert ist. Variablen, die auf Stufenebene definiert sind, überschreiben Variablen, die auf der „Root“-Ebene definiert sind, werden jedoch von Variablen überschrieben, die auf der Jobebene definiert sind.

Hier sehen Sie ein Beispiel für eine YAML-Build-Definition, bei der jeder Bereich verwendet wird.

variables:
  global_variable: value  # dies steht allen Stufen und Jobs zur Verfügung

stages:
- stage: Build
  variables:
    stage_variable1: value3 # verfügbar in Build-Stufe und allen Jobs
  jobs:
  - job: BuildJob
    variables:
      job_variable1: value1    # dies ist nur in BuildJob verfügbar
    steps:
    - bash: echo $(stage_variable1) ## funktioniert
    - bash: echo $(global_variable) ## funktioniert
    - bash: echo $(job_variable1) ## funktioniert

Variablenpriorität

Manchmal kommt es vor, dass eine Variable mit dem gleichen Namen in verschiedenen Bereichen festgelegt wird. In diesem Fall wird der Wert dieser Variable gemäß einer bestimmten Sequenz überschrieben, wobei die engste „Aktion“ Vorrang hat.

Im Folgenden sehen Sie die Reihenfolge, in der die Variablen überschrieben werden, beginnend mit einer in einem Job festgelegten Variable. Diese hat die höchste Priorität.

1. Variable auf Jobebene festgelegt (in der YAML-Datei festgelegt)
2. Variable auf Stufenebene festgelegt (in der YAML-Datei festgelegt)
3. Variable auf Pipelinenebene (global) festgelegt (in der YAML-Datei festgelegt)
4. Variable zum Zeitpunkt der Warteschlange festgelegt
5. Pipeline-Variable in der Pipeline-Einstellungen-Benutzeroberfläche festgelegt

Werfen Sie zum Beispiel einen Blick auf die YAML-Definition unten. In diesem Beispiel wird dieselbe Variable in vielen verschiedenen Bereichen festgelegt, endet jedoch letztendlich mit dem Wert, der in der Jobdefinition angegeben ist. Bei jeder Aktion wird der Wert der Variable überschrieben, wenn die Pipeline zum Job gelangt.

variables:
  foo: 'global variable'

stages:
- stage: build
  variables:
   - name: foo
     value: 'defined at stage level'

  jobs:
  - job: compile
    variables:
    - name: foo
      value: 'defined at job level'
    steps:
      - bash: echo $(foo) # Dies wird auf "auf Jobebene definiert" gesetzt

Variablentypen

In diesem Artikel haben Sie bereits gelernt, was Variablen sind, wie sie aussehen und in welchen Kontexten sie ausgeführt werden können. Was wir jedoch noch nicht behandelt haben, ist die Tatsache, dass nicht alle Variablen gleich sind. Einige Variablen existieren bereits, wenn eine Pipeline gestartet wird, und können nicht geändert werden, während andere nach Belieben erstellt, geändert und entfernt werden können.

Es gibt vier allgemeine Arten von Variablen: vordefinierte oder Systemvariablen, benutzerdefinierte Variablen, Ausgabevariablen und geheime Variablen. Lassen Sie uns jede dieser Arten von Variablen genauer betrachten.

Vordefinierte Variablen

In allen Builds und Veröffentlichungen finden Sie viele verschiedene Variablen, die standardmäßig vorhanden sind. Diese Variablen werden vordefinierte oder Systemvariablen genannt. Vordefinierte Variablen sind alle schreibgeschützt und stellen, wie andere Arten von Variablen, einfache Zeichenketten und Zahlen dar.

Eine Azure-Pipeline besteht aus vielen Komponenten, angefangen von dem ausführenden Softwareagenten für den Build, über die Jobs, die bei einer Bereitstellung erstellt werden, bis hin zu verschiedenen anderen Informationen. Um all diese Bereiche darzustellen, werden vordefinierte oder Systemvariablen informell in fünf verschiedene Kategorien unterteilt:

• Agent
• Build
• Pipeline
• Bereitstellungsaufgabe
• System

Es gibt Dutzende von Variablen, die in diesen fünf Kategorien verteilt sind. Sie werden in diesem Artikel nicht alles darüber erfahren. Wenn Sie eine Liste aller vordefinierten Variablen möchten, werfen Sie einen Blick in die Microsoft-Dokumentation.

Benutzerdefinierte Variablen

Wenn Sie eine Variable in einer YAML-Definition oder über ein Skript erstellen, erstellen Sie eine benutzerdefinierte Variable. Benutzerdefinierte Variablen sind einfach alle Variablen, die Sie als Benutzer in einer Pipeline definieren und verwenden. Sie können fast jeden Namen für diese Variablen verwenden, mit einigen Ausnahmen.

Sie können keine Variablen definieren, die mit den Wörtern endpoint, input, secret oder securefile beginnen. Diese Bezeichnungen sind tabu, da sie für die Systemnutzung reserviert sind und Groß-/Kleinschreibung nicht beachtet wird.

Zusätzlich müssen die von Ihnen definierten Variablen nur aus Buchstaben, Zahlen, Punkten oder Unterstrichen bestehen. Wenn Sie versuchen, eine Variable zu definieren, die diesem Format nicht folgt, funktioniert Ihre YAML-Build-Definition nicht.

Ausgabevariablen

A build definition contains one or more tasks. Sometimes a task sends a variable out to be made available to downstream steps and jobs within the same stage. These types of variables are called output variables.

Ausgabevariablen werden verwendet, um Informationen zwischen den Komponenten der Pipeline auszutauschen. Wenn beispielsweise eine Aufgabe einen Wert aus einer Datenbank abfragt und nachfolgende Aufgaben das Ergebnis benötigen, kann eine Ausgabevariable verwendet werden. Sie müssen dann nicht jedes Mal die Datenbank abfragen. Stattdessen können Sie einfach auf die Variable verweisen.

Hinweis: Ausgabevariablen sind auf eine bestimmte Phase beschränkt. Erwarten Sie nicht, dass eine Ausgabevariable sowohl in Ihrer „Build“-Phase als auch in Ihrer „Testing“-Phase verfügbar ist.

Geheime Variablen

Der letzte Variablentyp ist die geheime Variable. Technisch gesehen handelt es sich dabei nicht um einen eigenen unabhängigen Typ, da es sich um eine system- oder benutzerdefinierte Variable handeln kann. Aber geheime Variablen müssen in ihrer eigenen Kategorie sein, da sie anders behandelt werden als andere Variablen.

A secret variable is a standard variable that’s encrypted. Secret variables typically contain sensitive information like API keys, passwords, etc. These variables are encrypted at rest with a 2048-bit RSA key and are available on the agent for all tasks and scripts to use.

– Definieren Sie keine geheimen Variablen in Ihren YAML-Dateien
– Geben Sie geheime Variablen oder Protokollinformationen nicht als Ausgabevariablen zurück

Geheime Variablen sollten im Pipeline-Editor definiert werden. Dadurch werden geheime Variablen auf globaler Ebene bereitgestellt und in den Aufgaben der Pipeline verfügbar gemacht.

Geheime Werte werden in den Protokollen maskiert, aber nicht vollständig. Deshalb ist es wichtig, sie nicht in einer YAML-Datei einzuschließen. Sie sollten auch wissen, dass keine „strukturierten“ Daten als Geheimnis eingebunden werden dürfen. Wenn zum Beispiel { "foo": "bar" } als Geheimnis festgelegt ist, wird bar nicht in den Protokollen maskiert.

Geheimnisse werden nicht automatisch entschlüsselt und als Umgebungsvariablen zugeordnet. Wenn Sie eine geheime Variable definieren, erwarten Sie nicht, dass sie beispielsweise in einem PowerShell-Skript über $env:FOO verfügbar ist.

Variablen-Gruppen

Zuletzt kommen wir zu den Variablen-Gruppen. Variablen-Gruppen sind, wie der Name schon sagt, „Gruppen“ von Variablen, die als eine referenziert werden können. Der Hauptzweck einer Variablen-Gruppe besteht darin, Werte zu speichern, die in mehreren Pipelines verfügbar sein sollen.

Im Gegensatz zu Variablen werden Variable-Gruppen nicht in der YAML-Datei definiert. Stattdessen werden sie auf der Seite Bibliothek unter Pipelines in der Benutzeroberfläche definiert.

Verwenden Sie eine Variable-Gruppe, um Werte zu speichern, die Sie steuern und in mehreren Pipelines verfügbar machen möchten. Sie können Variable-Gruppen auch verwenden, um Geheimnisse und andere Werte zu speichern, die an eine YAML-Pipeline übergeben werden müssen. Variable-Gruppen werden wie unten auf der Seite Bibliothek unter Pipelines definiert und verwaltet.

Nachdem sie in der Pipeline-Bibliothek definiert wurden, können Sie auf die Variable-Gruppe in der YAML-Datei mit der unten stehenden Syntax zugreifen.

variables:
- group: group1

Variable-Gruppen sind standardmäßig nicht für alle Pipelines verfügbar. Diese Einstellung wird beim Erstellen der Gruppe festgelegt. Pipelines müssen autorisiert sein, eine Variable-Gruppe zu verwenden.

Nachdem eine Variable-Gruppe in der YAML-Datei zugänglich gemacht wurde, können Sie auf die Variablen innerhalb der Gruppe genau wie auf jede andere Variable zugreifen. Der Name der Variable-Gruppe wird nicht verwendet, wenn auf Variablen in der Gruppe verwiesen wird.

Zum Beispiel, wenn Sie eine Variable-Gruppe namens group1 mit einer Variable namens foo definiert haben, würden Sie auf die Variable foo wie jede andere Variable zugreifen, z.B. $(foo).

In einer Variable-Gruppe definierte geheime Variablen können nicht direkt über Skripte zugegriffen werden. Stattdessen müssen sie als Argumente an die Aufgabe übergeben werden.

Wenn eine Änderung an einer Variablen in einer Variable-Gruppe vorgenommen wird, wird diese Änderung automatisch allen Pipelines zur Verfügung gestellt, die berechtigt sind, diese Gruppe zu verwenden.

Zusammenfassung

Sie sollten nun über solide Kenntnisse zu Azure Pipelines-Variablen verfügen. Sie haben in diesem Artikel praktisch jedes Konzept rund um Variablen gelernt! Nutzen Sie dieses Wissen jetzt in Ihren Azure DevOps Pipelines und automatisieren Sie alles!