TFS2015 vNext fehlende Funktionen

Question

Ich habe mit TeamCity, Jenkins und Bamboo meine letzten 8 Jahre gearbeitet. Die letzten 2 Jahre waren sehr involviert in ContinuousIntegration Factory Setup und Maintenance in meinem Team mit sehr guten Ergebnissen, die mir eine Menge Gewohnheiten über den Umgang mit Builds, Artefakten und Pipelines geben.

Jetzt bin ich auf eine neue Firma, neues Team, neues CI, TFS2015, erstes Mal für mich.

Nur einen Monat bevor ich zu diesem neuen Team kam, waren sie auf TFS2012, mit XAMLs, also nahm ich die Migration zu vNext-Builds.

Auf den ersten Blick habe ich bei vNext builds die klassische Build-Definition gefunden, ich meine das Hinzufügen von Schritten als eine einzige Aufgabe zum Build, anstatt einer monolithischen XAML-Datei.

Aber mit der Zeit, ich habe versucht, komplexere baut zu schaffen, wie Teamcity Ketten bauen, aber das ist nicht möglich, Streik ein ...

Dann habe ich versucht, mit mehreren Zweigen zu beschäftigen, ein Kontinuierlicher Build für jeden Zweig (wir sind auf TFSVC), erstellen Pakete aus jedem Zweig, und ich fand, dass ich meine Builds duplizierte, nur um Repository-Pfade und ein paar Details zu ändern, also habe ich Builds in Templates verschoben, die versuchen, Build-Definitionen wieder zu verwenden um Pfade (für Repos und Zweige) und Versionen zu erzeugen und zu erwarten, dass sie nur an einer Stelle den Build ändern und sich diese Änderungen in allen von Templates abgeleiteten Builds widerspiegeln ... aber das war nicht der Fall ...:

Variablen werden nicht überall akzeptiert, wie in Repo-Pfaden.

Vorlagen können nach dem Erstellen nicht geändert werden, ersetzen Sie sie einfach, und Builds, die aus Vorlagen erstellt wurden, sind nicht betroffen, nachdem die Vorlage geändert wurde. strike two? .....

Ich frage mich, ob ich vielleicht etwas falsch mit TFS mache, vielleicht ist dies ein anderes System, und ich kann Dinge wie in anderen CIs nicht tun.

Irgendwelche Ratschläge, wie man sich an TFS annähert, um einen guten, dynamischen und wiederverwendbaren Satz von Builds zu haben?

Answer 1

Hier ist nicht das Feature, dass die Änderungen einer Builddefinition oder einer Vorlage sich auf andere vorhandene Builddefinitionen auswirken.

Wenn die Build-Schritte der Builddefinitionen für jeden Zweig identisch sind, benötigen Sie nur eine Builddefinition und Filter für jeden Zweig (Trigger> Continuous integrations (CI)). Danach wird die entsprechende Quelle für CI verwendet bauen, zum Beispiel entwickeln Zweig Änderungen> Trigger einen Build automatisch mit Zweig Quelle entwickeln.

Auf der anderen Seite können Sie Zweig und Source-Version ändern, wenn Warteschlange Build manuell oder durch REST API.

Wenn Die Build-Schritte sind für jeden Zweig unterschiedlich. Sie müssen die Definitionen unabhängig von den Detailanforderungen ändern.