TFS 2010-Verzweigungsmodell für eine interne Anwendung

Question

Dies ist keine Frage, bei der ich keine Ideen habe, sondern ich möchte ein Modell vorstellen und prüfen, ob es genehmigt wird oder ob jemand Probleme damit sieht oder bessere Vorschläge hat. Sie sagen, es sei besser, das Verzweigungsmodell sorgfältig auszuwählen, um zukünftige Kopfschmerzen zu vermeiden.

Wir haben also eine interne Anwendung mit nur einer Version (der neuesten), die für die Kunden freigegeben wurde, und im Grunde gibt es zwei Arten von Entwicklungsaktivitäten: Die Hauptaktivität arbeitet für die nächste Version und umfasst normalerweise neue Funktionen und Korrekturen und es ist geplant, und die zweite, die nicht geplant ist und sich mit Wartung befasst und Hotfixes der aktuellen Version in der Produktion enthält.

Nach langer Recherche haben wir uns für einen Hauptstamm entschieden, von dem wir zwei untergeordnete Zweige abzweigen: Entwicklung und Wartung (oder Hotfix ). Wie im Handbuch dargestellt, würde die tägliche Entwicklung im Zweig Entwicklung stattfinden, von wo aus wir jedes Mal Reverse Integration (RI) durchführen, wenn wir Funktionen für die nächste Version bereit haben. Kurz vor der Veröffentlichung wird die umgekehrte Integration gestoppt und der Code im Zweig Main stabilisiert. Nach der Veröffentlichung von Main erfolgt eine Vorwärtsintegration (FI) von Main zu Entwicklung und Wartung . < / p>

Jeder Hotfix wird nur in Wartung ausgeführt. Abhängig vom Fix (z. B. wenn wir ihn in der Codebasis behalten möchten) führen wir eine RI in Main und durch von dort ein FI in Entwicklung .

Jetzt sieht alles in Ordnung aus, zumindest auf dem Papier, daher würde ich gerne die Meinungen anderer zu diesem Modell hören.

Zum Beispiel würden wir auch einen anderen Zweig in Betracht ziehen, Release , in dem die Stabilisierung des Codes vor einer Freigabe für die Produktion erfolgt (anstatt direkt in Main zu arbeiten) und Natürlich werden wir von hier aus die Produktion freigeben und einen RI in Main durchführen, gefolgt von einem FI in Development & Maintenance , aber das sind wir nicht sicher, ob dies einen Nutzen bringt oder nur die Komplexität erhöht?

Und unter der Annahme, dass es Funktionen in der Entwicklung gibt, die für die nächste Version nicht bereit oder nicht erwünscht sind, bedeutet dies, dass wir einige "Cherry Picking" der zugehörigen Änderungssätze durchführen müssen zu den gewünschten Funktionen, aber das ist laut den Dokumenten nicht zu gut. Irgendwelche Vorschläge?

Wiederum weiß ich, dass es keine einfache, unkomplizierte, sondern eine offene Frage ist. Trotzdem hoffe ich, von jemandem mit einer ähnlichen Erfahrung zu hören. Vielen Dank im Voraus für Ihre Aufmerksamkeit.

Answer 1

Haben Sie die Dokumentation zu TFS ALM Rangers Branching Guidance gelesen?Was Sie vorschlagen, sieht dem "Standard-Zweigstellenplan" ziemlich ähnlich, obwohl sie sowohl eine Release- als auch eine "Service Pack" -Zweigstelle empfehlen (ähnlich wie Ihre oben genannten Release- und Wartungszweige).

http://vsarbranchingguide.codeplex.com/

Ich habe den Standard-Verzweigungsplan bei einigen Kunden implementiert und hatte kein Problem damit.Wenn Sie vorhaben, gleichzeitig Arbeitsströme (Feature-Crews usw.) zu übernehmen, enthält die Branching Guidance auch dafür solide Pläne.

Eine andere zu berücksichtigende Sache könnte ein Treppenstufenmodell sein, bei dem Sie bei jeder Version neue Entwicklungszweige erstellen und die alte als Version einfrieren.Dies würde RIs vermeiden, da Sie nur den alten Hotfix und bei Bedarf den Fix für den neuen Dev-Zweig ausführen können.Ich habe auch in diesem Modell gearbeitet und es war großartig.