Verzweigungs- und Zusammenführungsstrategien

Question

Ich habe die Aufgabe, in den nächsten sechs Monaten eine Strategie für die Verzweigung, Zusammenführung und Freigabe zu entwickeln.

Die Komplikation kommt von der Tatsache, dass wir mehrere Projekte mit verschiedenen Codeänderungen und verschiedenen Veröffentlichungsterminen ausführen werden, aber ungefähr die gleichen Entwicklungsbeginndaten.

Gegenwärtig verwenden wir VSS für die Codeverwaltung, aber wir sind uns bewusst, dass es wahrscheinlich einige Probleme verursachen wird und vor Beginn der neuen Entwicklung auf TFS migriert werden wird.

Welche Strategien sollte ich anwenden und welche Dinge sollte ich berücksichtigen, bevor ich einen Plan aufstelle?

Tut mir leid, wenn dies vage ist, zögern Sie nicht, Fragen zu stellen, und ich werde mit mehr Informationen aktualisieren, falls erforderlich.

Answer 1

Dies ist die einzige beste source control pattern, die ich gestoßen bin. Es betont, wie wichtig es ist, den Stamm frei von jeglichem Müll zu lassen (kein Müll im Kofferraum). Die Entwicklung sollte in Entwicklungszweigen erfolgen, und regelmäßige Zusammenführungen (nachdem der Code getestet wurde) sollten in den Stamm zurückgeführt werden (Bild 1), aber das Modell ermöglicht auch, dass die Quelle während der Entwicklung gepatcht wird (Bild 2). Ich empfehle definitiv, den Beitrag in seiner Gesamtheit zu lesen, um vollständig zu verstehen.

  Pic 1

  Pic 2

Edit: Die Bilder sind auf jeden Fall verwirrend ohne Worte. Ich könnte es erklären, aber ich würde im Grunde den ursprünglichen Autor kopieren. Nachdem ich das gesagt habe, hätte ich wahrscheinlich ein besseres Bild für die Beschreibung des Merge-Prozesses wählen sollen, also hoffentlich hilft das. Ich würde jedoch empfehlen, den Beitrag zu lesen, jedoch:

Answer 2

Das Subversionsbuch beschreibt some common branching patterns. Vielleicht können Sie diese auch auf TFS anwenden.

Answer 3

Meine erste Empfehlung wäre Eric Sink des Source Control HOWTO zu lesen - speziell auf die branches und branch merge Kapiteln.

Wir haben 3 Container - DEV, MAIN und RELEASE für unsere Arbeit. MAIN enthält all unseren "ready-to-release" -Code und wir betrachten ihn als "grundsätzlich stabil". DEV/Iteration (oder DEV/Feature oder DEV/RiskyFeatureThatMightBreakSomeoneElse) sind Zweige von MAIN und werden zusammengeführt, wenn die Iteration/Feature bereit ist, über die DEV-Umgebung hinaus zu promoten. Wir haben auch TFS-Builds, die aus dem Zweig DEV/Iteration und dem Zweig MAIN erstellt wurden.

Unser RELEASE-Container enthält nummerierte Releases (ähnlich dem "tags" -Container, der in vielen Subversion-Repositorys verwendet wird). Wir nehmen einfach jedes Mal eine Verzweigung von MAIN - ich würde gerne sagen, dass wir einen RELEASE-Zweig "schneiden", um anzuzeigen, dass dies nach dem Abschluss der Zusammenführung nicht viel Aktivität haben sollte.

Wie für VSS-> TFS - Microsoft unterstützt ein upgrade path die Ihre Version der Geschichte halten sollte, aber wenn Sie es die Geschichte nicht brauchen, ich würde nur die neueste Version von VSS erhalten, überprüfen sie in TFS und Archivieren Sie das VSS-Repository.

Ein letzter Tipp - machen Sie Ihre Teammitglieder mit der Quellcodeverwaltung vertraut. Sie müssen verstehen, verzweigen und verschmelzen oder Sie werden stecken tun eine Menge Aufräumarbeiten :).

Viel Glück!

Answer 4

Die einfachste und üblichste Art, Verzweigung zu sehen, ist aus zwei Gründen. Trunk und Release. Ich denke, das ist bekannt als die Philosophie "Instabiler Stamm, stabiler Zweig".

Stamm ist Ihre Hauptquelle. Dieses enthält den "neuesten und größten" Code und ist zukunftsorientiert. Es ist im Allgemeinen nicht immer stabil.

Release ist eine Eins-zu-viele-Verbindung mit Trunk. Es gibt einen Trunk, aber viele Releases, die vom Trunk stammen. Releases beginnen in der Regel mit einem Zweig des Trunks, sobald ein bestimmter Funktions-Meilenstein erreicht wurde, so dass die "einzigen" Dinge, die für eine bestimmte Implementierung übrig bleiben, nur Fehlerbehebungen sein sollten. Dann verzweigen Sie den Stamm, geben Sie ihm ein Label (z. B. 1.6 Release ist unser derzeitiges Release), erstellen und senden Sie das Release an QA.Wir drücken auch die Versionsnummer (normalerweise die Minor-Nummer) des Trunks an diesem Punkt, um sicherzustellen, dass wir nicht zwei Releases mit derselben Nummer haben.

Dann beginnen Sie den Testzyklus auf Ihrem Release-Zweig. Wenn genügend Tests durchgeführt wurden, wenden Sie Fehlerkorrekturen auf den Versionszweig an, führen diese zurück zum Stamm (um sicherzustellen, dass Bugfixes weitergeführt werden!) Und geben dann einen Build des Zweigs erneut frei. Dieser Zyklus mit QA setzt sich fort, bis Sie beide glücklich sind und die Freigabe schließlich dem Kunden (den Kunden) gegeben wird. Alle Fehlerberichte von den Kunden, die genau sind (d. H. Sie sind ein Fehler!), Starten einen weiteren QA-Zyklus mit der fraglichen Verzweigung.

Wenn Sie zukünftige Versionen erstellen, ist es eine gute Idee, auch ältere Kunden auf neuere Zweigstellen zu verschieben, um die potentielle Anzahl von Verzweigungen zu reduzieren, in die Sie einen Fehler beheben können.

Mit dieser Technik können Sie Lösungen mit Ihrer Technologie für eine Vielzahl von Kunden bereitstellen, die unterschiedliche Service-Levels erfordern (beginnend mit mindestens dem ersten). Sie können Ihre vorhandenen Bereitstellungen von "gefährlichem" neuem Code im Stamm und dem Schlimmsten isolieren Zusammenführungsszenario ist ein Zweig.