Verwalten einer Build alle Lösung in TFS

Question

Ich bin der TFS-Administrator in meiner Firma. In der Vergangenheit habe ich eine lineare Verzweigungsstrategie für kleine Teams empfohlen, die auch für TFS neu sind. Starten Sie in Dev> Dev bis zu Test> Test zusammenführen bis Prod.

Dies funktioniert gut mit Lösungen, deren Projekte Unterverzeichnisse der Lösung sind. Was ist mit Projekten, die in der Quellcodeverwaltung verteilt sind?

Kann ich einen einzelnen Zweig erstellen, der Projekte verwalten kann, die an verschiedenen Stellen in der Quellcodeverwaltung verteilt sind?

E.G.

\ $ TFS \ Dev \ Project1
\ $ TFS \ Dev \ SomeFolder \ Projekt2
\ $ TFS \ Dev \ SomeOtherFolder \ Project3

Wir haben ein Hauptprojekt, die alle unsere Baugruppen untergebracht ist. Dieses Projekt ist das "build all" -Projekt. Es wird mit finalBuilder pro verwendet, um die Bereitstellung auf der nächsten Ebene durchzuführen. Das Problem ist, dass diese Projekte über die gesamte Quellcodeverwaltung verteilt sind. Ich bin mir nicht sicher, wie ich sie handhaben soll.

Answer 1

Ja. Mit Team Build können Sie nicht nur branchenübergreifende Lösungen erstellen, sondern auch Lösungen für verschiedene Teamprojekte erstellen. Ich denke jedoch, dass es am besten ist, jedes Projekt und jede Branche mit einer eigenen Build-Definition zu versehen.

In Ihrem Fall würde ich zuerst versuchen, organize the source tree, dann definieren Sie eine Master-Lösung, die alle Projekte erstellt. FinalBuilder sollte dein Szenario unterstützen, obwohl ich denke, FinalBuilder ist überflüssig, wenn du TFS hast.

Answer 2

Mein Vorschlag ist es, zu identifizieren, welche "Projekte" unabhängig voneinander freigegeben und versioniert werden, und separate Verzweigungsstrukturen für jede davon haben.

Sie möchten nicht 2 unabhängige Projekte (unabhängig voneinander, ich meine, sie werden separat freigegeben/versioniert) innerhalb derselben Verzweigungsstruktur haben.

Die typische Möglichkeit, Abhängigkeiten zwischen diesen Projekten zu verwalten, besteht darin, die Binärdateien von Project 1 Version X in den "lib" -Ordner von Project 2 einzuchecken. Auf diese Weise können Sie nach Belieben neue Versionen von Projekt 1 veröffentlichen, aber das Projekt 2-Team kann entscheiden, wann und ob es eine Abhängigkeit von der neuen Version geben soll.

Wenn Ihre verschiedenen "Projekte" alle Teile der einen großen Sache sind, die zusammen veröffentlicht/versioniert wird, dann würde ich empfehlen, nur sicherzustellen, dass sie alle in einem Stammordner (zB $ \ TFS \ Dev) leben und verzweigen von dort.