TFS 2015 erstellt: Ist es möglich, Variablen in Repository-Mappings zu verwenden?

Question

Beim Erstellen eines vNext-Builds auf TFS 2015 können Sie Variablen definieren, die dann in Build-Schritten verwendet werden und auch als Umgebungsvariablen in Skripts verwendet werden können, die im Build ausgeführt werden.

Der Build, an dem ich arbeite, führt Skripts aus, die Dateien von zugeordneten Speicherorten abrufen. Daher wäre es großartig, wenn ich eine Variable definieren und in einem Mapping verwenden könnte, um beispielsweise im Projekt eine Referenz zu aktualisieren Build erstellt, ich kann einfach die Variable mit dem neuen Speicherort aktualisieren und die Repository-Zuordnungen und Skripts alle korrekt vom neuen Speicherort abrufen, ohne die Änderung an mehreren Stellen vornehmen zu müssen.

Ich habe versucht, dies zu tun, indem Sie die Variable und Mapping-Einrichtung wie folgt Aber dies erzeugt einen Fehler, wenn Sie versuchen, den Build zu speichern beschweren, dass es zwei Zeichen ‚$‘ in der Abbildung. Gibt es einen Weg dies zu tun oder ist das momentan nicht möglich?

Answer 1

Es ist unmöglich. Genauso wie die Fehlermeldung: Es gibt zwei '$' Zeichen im Mapping. Dies bedeutet, dass der Pfad Ihrer Anwendung nicht von Build zu Build variieren sollte.

Mappings auf der Repository-Seite verwendet werden, um die Quellcodeverwaltung Ordner angeben, welche Projekte enthält, die in der Build Definition gebaut werden müssen. Sie können es durch Klicken auf die Schaltfläche Ellipse (...), , festlegen. Sie können jedoch keine Variablen in den Mapping-Pfad aufnehmen.

Es gibt eine ähnliche Frage: Variables in TFS Mappings on Visual Studio Online Team Builds

Answer 2

Dies wurde verursacht mich auch für eine ganze Weile Havok.

Für den Anfang gibt es eine Uservoice-Anfrage für diese Funktion. Sie können Ihre Stimmen hinzufügen und hier eingeben, um Microsoft diese Funktion zu ermöglichen: https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/14131002-allow-variables-in-repository-variables-and-trigg

Zweitens haben wir eine Problemumgehung entwickelt, die uns den größten Teil des Weg dorthin erhält. Es ist nicht perfekt, aber es könnte für Sie nützlich sein, wenn Sie mit den Kompromissen vertraut sind oder die Mängel umgehen können.

Beginnen Sie mit der Deaktivierung der Option "Label Sources" des Builds und weisen Sie das Feld "Server Path" Ihrem Basis-Build zu. Sie möchten der Builddefinition eine benutzerdefinierte Variable hinzufügen, um der Buildinstanz mitzuteilen, welchen TFS-Speicherort Sie verwenden möchten. Zum Beispiel haben wir ein Projekt Basis und dann mehrere Zweige aus dem Projekt, so unsere Quelle ist wie dies

$\Team Project\Project1 
$\Team Project\Project1Branch1 
$\Team Project\Project1Branch2 
$\Team Project\Project1Branch3 

strukturiert und wir erstellen eine Variable mit dem Namen „Filiale“, die wir „Branch1“ gesetzt, „Branch2 ", und so weiter.

Wenn wir das Basisprojekt erstellen möchten, lassen wir die Branch-Variable beim Start des Builds leer. Für Branch-Builds legen wir den Namen des Zweigs fest, den wir erstellen möchten.

Dann schauen unsere Build-Schritte wie diese

• Neuzuordnung Arbeitsbereich Ordner zu verzweigen Ordner
• Erhalten Sie Dateien für Angegebene Niederlassung - Wir haben diese nach manuell tun unser Arbeitsplatz Remapping
• Kompilieren Sie die Quelle in Der angegebene Zweig
• Veröffentlichen von Build-Artefakten aus dem angegebenen Zweig
• Manuelles Beschriften des Codes der angegebenen Verzweigung

Die Neuzuordnung Task führt den Befehl

tf workfold "$/Team Project/Project1$(Branch)" "$(build.sourcesDirectory)\$(Build.DefinitionName)$(Branch)" 

Das Handbuch Get Task führt den folgenden Befehl

get /recursive /noprompt "$/Team Project/Project1$(Branch)" 

Der Build der Zweig Variable verwendet, um die richtige Stelle der Lösung Datei zu zeigen für den spezifizierten Zweig

$(build.sourcesDirectory)\$(Build.DefinitionName)$(Branch)\SolutionFile.sln 

Die Publ ish Artefakte Aufgabe verwendet die Branche Variable sowohl im Feld Inhalt und das Feld Pfad Beispiel in Inhalt

**\$(Build.DefinitionName)$(Branch)\bin 

Die Bezeichnung Code Aufgabe den folgenden Befehl

tf label "$(build.buildNumber)" "$/Team Project/Project1$(Branch)" /recursive 

Der Nachteil dieser Einrichtung, dass Sie ist verwendet Erfassen Sie keine assoziierten Änderungen und Arbeitselemente in Ihren Zweigstellen, da das Feld Serverpfad immer auf den Hauptstandort festgelegt ist. Dies ist möglicherweise kein Problem, wenn Sie immer von Ihren Niederlassungen zu Ihrem Hauptstandort zusammenführen, bevor Sie einen Build starten, der in die Produktion gehen soll. Was Sie tun können, um dies zu kompensieren, hängt von Ihrem Anwendungsfall ab.

Mit einigen Optimierungen könnten Sie dieses Format verwenden, um auch vollständige Pfade anzugeben, wenn Sie dies benötigen.