TFS-Builddefinitionen und Veröffentlichungsmanagement-Best Practices mit mehreren Zweigen und Lösungen

Question

Ich verwende derzeit Team Foundation Server 2015 (Update 2) und möchte die neuen Builddefinitionen und das Versionsmanagement verwenden und mich fragen, was die beste Vorgehensweise beim Erstellen von Build ist Definitionen bei Verwendung mehrerer Zweige.

Wir haben mehrere Zweige und es gibt auch mehrere Lösungen in jedem Zweig (für dieses Beispiel werde ich sie WinApp.sln, WebApp.sln & MobileApp.sln nennen).

Unsere Projekt Zweige sind so etwas wie die folgenden ...

Project 
    Dev 
     Main *** This is our development branch for new features 
     Updates 
      1.2 *** This branch is used for any bug fixes for version 1.2 
    Main 
    Releases 
     1.1 
     1.2  *** Current release branch that will be deployed to customers 

die neuen Build-Definitionen in TFS 2015 verwenden Sie am besten eine neue Build-Definition für jeden der Zweige oder jeder der Anwendungen zu erstellen, in jeder Zweig.

Zum Beispiel erstelle ich die folgenden bauen Definitionen:

AppName.Dev.WinApp 
AppName.Dev.WebApp 
AppName.Dev.MobileApp 
AppName.Updates.1.2.WinApp 
AppName.Updates.1.2.WebApp 
AppName.Updates.1.2.MobileApp 
AppName.Release.1.2.WinApp 
AppName.Release.1.2.WebApp 
AppName.Release.1.2.MobileApp 

Und dann, die durch mit Release-Definitionen wie folgt bis zum Release-Management fließen würde:

AppName.Dev   
AppName.Updates.1.2 
AppName.Release.1.2 

Jede Version Definition haben Artefakte, die für jeden der 3 Lösungsaufbauten hinzugefügt wurden.

Oder wäre es besser, nur eine Builddefinition für jeden Zweig zu haben?

Wäre interessant zu wissen, was andere Leute in ähnlichen Situationen tun.

Answer 1

Zuvor hatten wir mit den xaml-basierten Builds mehrere Build-Definitionen, da wir bei der Veröffentlichung einer neuen Build-Vorlage nicht auf die Builddefinitionen der älteren Version Einfluss nehmen wollten. Daher haben wir mehrere Builddefinitionen beibehalten. Wir haben auch behauptet, dass wegen der Version der Build bekommt.

Aber mit den neuen vNext-Builds gibt es keine Möglichkeit, eine frühere Version eines Tasks zur Verfügung zu haben, sobald wir einen Task erweitern und ihn zum TFS hochladen. Alle Build-Definitionen beginnen mit der neuesten Task und dort ist keine Möglichkeit (außer dem Umbenennen einer Aufgabe), mit der wir eine Aufgabe älterer Version auswählen können. Also, ich denke, es wäre nutzlos, mehrere Build-Definitionen zu pflegen, da die Build-Definitionen aktualisiert werden, wenn eine Aufgabe aktualisiert wird.

Es gibt einen Fall, in dem wir eine Version für ein bestimmtes Release bereitstellen müssen. Wenn die Anzahl von den ausgelösten Builds abhängt, haben wir in diesem Fall unterschiedliche Builddefinitionen, da unsere Patches nicht die neueste Versionsnummer haben können.

Ein weiterer Grund, eine andere Builddefinition beizubehalten, besteht darin, sich von den Kopfschmerzen zu befreien, sich daran zu erinnern, welche Aufgaben zuvor in einer bestimmten Version verwendet wurden.

Alles in allem werde ich mit verschiedenen Build-Definitionen gehen, um Versions-Chaos und Maitain Integrität einer Release-Build-Definition zu vermeiden.

Wenn es zur Freigabe kommt, binden wir eine Build-Definition an eine Release-Definition. Um also einen reibungslosen Bugfix und ein Update zu erhalten, müssen verschiedene Release-Definitionen für jede Builddefinition vorhanden sein.