Umgebungsvariablen in Build vNext verwenden

Das neue Build-System, das in Visual Studio Team Services (VSTS) und TFS 2015 eingeführt wurde, erfreut sich in letzter Zeit immer größerer Beliebtheit, und das (meiner Meinung nach) zu Recht. Es funktioniert einfach viel besser als die alten XAML-Builds. Ich habe eine ganze Reihe von XAML-basierten Builds in das neue Build-System konvertiert. Dabei bin ich (natürlich unweigerlich) auf eine ganze Reihe von benutzerdefinierten Build-Workflows und -Aufgaben gestoßen. Einige davon ließen sich leicht in Build-Aufgaben umwandeln, die sofort zur Verfügung stehen, während andere einige benutzerdefinierte Aufgaben erforderten. Wenn Sie einen benutzerdefinierten Build oder eine benutzerdefinierte Build-Aufgabe erstellen, benötigen Sie irgendwann einige build-spezifische Informationen. An dieser Stelle werden Umgebungsvariablen notwendig. Da ich mit dem Konzept nicht allzu vertraut war (ich hatte zwar davon gehört, sie aber nie wirklich benutzt), beschloss ich, etwas tiefer zu graben.

Was ist eine Umgebungsvariable?

Umgebungsvariablen sind ein Konzept innerhalb des Betriebssystems. Sie sind eine Reihe von Schlüssel-Wert-Paaren, die für die Umgebung Ihres aktuellen Prozesses spezifisch sind. Die Verwendung von Umgebungsvariablen ist bei den meisten Betriebssystemen, wie Windows, Linux und Mac OS X, gut bekannt. Das macht sie in plattformübergreifenden Szenarien, wie z.B. einem Build-Agent, sehr nützlich.

Einige Beispiele für gängige Umgebungsvariablen sind "PATH" (eine Liste von Verzeichnissen, in denen nach einem von Ihnen ausgeführten Befehl gesucht wird), "TEMP" (der Pfad zum Speichern temporärer Dateien) und "WINDIR" (der Pfad zum Windows-Installationsverzeichnis).

Umgebungsvariablen im Erstellungsprozess

Im Kontext eines Build-Jobs ist der aktuelle Prozess die Ausführung Ihrer Build-Definition. Daher sind alle in diesem Kontext erstellten Umgebungsvariablen für alle Aufgaben in Ihrer Build-Definition verfügbar! Das bedeutet, dass Sie Umgebungsvariablen innerhalb Ihrer Build-Aufgaben verwenden können, um die Ausführung der Build-Aufgabe zu steuern. Außerdem können Sie Informationen von einer Aufgabe an andere Aufgaben weitergeben, die dem Build-Prozess nachgelagert sind.

Es gibt mehrere Quellen für die Einstellung der Umgebungsvariablen:

• Das Betriebssystem Ihres Build-Servers: setzt Variablen auf Serverebene wie "TEMP" und "PATH",
• Der Build-Agent: setzt einige Variablen, die für die Ausführung eines Builds spezifisch sind, z.B. den Arbeitsordner des Agenten und Dinge wie die Build-Definition, die ausgeführt wird, und die Build-Nummer,
• Die Build-Definition: Alle Variablen, die Sie auf der Registerkarte "Variablen" in Ihrer Build-Definition festlegen (entweder in der Definition selbst oder beim Einstellen eines Builds in die Warteschlange), sind als Umgebungsvariablen im Build-Auftrag verfügbar.
  

Weitere Informationen zu Umgebungsvariablen in Ihrer Build-Definition finden Sie unter: Vordefinierte Variablen verwenden

Alle Umgebungsvariablen anzeigen

Die obige MSDN-Seite enthält eine Liste der vordefinierten Variablen, die in Ihrem Build-Job zur Verfügung stehen. Sie bietet zwar einen guten Einblick, aber das war mir nicht genug. Ich wollte wissen, welche Umgebungsvariablen verfügbar sind und welche Werte sie während der Ausführung eines Builds tatsächlich haben. Wie sich herausstellte, ist es gar nicht so schwer, alle Umgebungsvariablen und ihre Werte auszugeben. In der PowerShell kann dies mit erreicht werden:

Get-ChildItem Env:

Und in Node.js gibt es ein Objekt, das alle Umgebungsvariablen enthält:

process.env

Sie könnten dies in den Code einer beliebigen benutzerdefinierten Build-Aufgabe einbauen, die Sie entwickeln. Ich habe mich jedoch dafür entschieden, dies in eine kleine benutzerdefinierte Build-Aufgabe zu packen, die alle Umgebungsvariablen und ihre entsprechenden Werte ausgibt. Dies ermöglicht eine einfache Fehlersuche, indem Sie die Aufgabe einfach an einer beliebigen Stelle in Ihren Build-Prozess einfügen. Sie können die Aufgabe sogar mehrmals einbinden, um zu sehen, ob und wie Umgebungsvariablen zwischen den Aufgaben geändert wurden.

Die Ausgabe der Aufgabe sieht in etwa so aus:

Wie Sie sehen können, sind viele Umgebungsvariablen definiert. In meinem Fall waren es 114...

Den Code für diese Aufgabe finden Sie auf GitHub. Sie können ihn gerne verwenden!

Hoffentlich hilft Ihnen das, zu verstehen, was in Ihren Builds vor sich geht.

Viel Spaß beim Bauen!

[Dieser Beitrag wurde auf Niederländisch auf dem Delta-N Blog veröffentlicht.]