Bestes Setup für Code Promotion und Feature Branching in Subversion?

Question

Wir sind ein 4-köpfiges Team und haben uns in den letzten Jahren nicht weit von unserer Komfortzone entfernt, aber wir wachsen und möchten den Anschluss an die Zeit finden. Ich wurde damit beauftragt, den besten Weg zur Implementierung von Continuous Integration zu finden (automatisierte Builds, Verzweigungen für die Code-Wartung und neue Funktionen usw.). Wir überlegen, von SourceSafe 2005 zu Subversion zu wechseln, um unsere Versionskontrolle zu verwalten. Nach dem, was ich gelesen habe, ist Subversion eine viel bessere Wahl für die Code-Promotion, Verzweigungen und das Zusammenführen zwischen Verzweigungen. Wir werden wahrscheinlich die folgenden Produkte verwenden:

• VisualSVN-Server
• TortoiseSVN (für die Integration mit dem Windows Explorer)
• VisualSVN (für die Integration mit Visual Studio 2005)
• SVNVB6 (für die Integration mit Visual Basic 6)
• FinalBuilder

Wie organisiert man das Repository am besten für Code Promotion und Feature Branching? Hier ist ein Beispiel für unsere aktuelle SourceSafe-Struktur:

• Wurzel
  • Visual Studio 2005-Projekte
    • Projektname
      • Lösungsdatei, Projektdateien und Codedateien hier
      • \bin
        • \Release
          • Kompilierte Release-Binärdateien hier
  • Visual Basic 6-Projekte
    • Projektname
      • Projektdateien und Codedateien hier
      • Kompilierte Binärdateien (.dll, .exe, .ocx) hier
  • Dokumentation
    • Dokumentationsdateien hier

Sollten wir so strukturieren?

• Wurzel
  • Zweige (jeweils vom Stamm abgezweigt)
    • Entwicklung.FeatureA
    • Entwicklung.FeatureB
    • Test (nächtlich mit FinalBuilder erstellt??)
    • Produktion (nächtliche Erstellung mit FinalBuilder ???)
    • Production.BugFixA (Rückwärtsintegration in Produktionszweig, Testzweig und Stamm)
  • tags
    • Development.v1 (markiert nach jedem erfolgreichen Build)
    • Entwicklung.v2
    • Entwicklung.v3
    • Test.v1
    • Test.v2
    • Test.v3
    • Produktion.v1
    • Produktion.v2
    • Produktion.v3
  • trunk (Entwicklungscode - nächtlich mit FinalBuilder erstellt)
    • Visual Studion 2005 Projekte
      • Projektname
        • Lösungsdatei hier
        • Projektname
          • Projektdateien und Codedateien hier
    • Visual Basic 6-Projekte
      • Projektname
        • Projektdateien und Codedateien hier

Da ein großer Teil unserer Software noch COM (VB6) ist und registriert werden muss (mit regsvr32), sollten die Binärdateien versionskontrolliert sein? Wie sollten wir die Registrierung/Deregistrierung der Komponenten handhaben, wenn wir an verschiedenen Zweigen arbeiten müssen (möglicherweise mit unterschiedlicher COM-Kompatibilität)?

Sind wir weit vom Ziel entfernt?

Answer 1

Verwenden Sie zunächst keine Stammzweig-Tags auf oberster Ebene, sondern pro Projekt Stammzweig-Tags wie dieses:

/Projects
  /CashCowProject
    /branches
    /tags
    /trunk
      /vs
      /doc

Das bedeutet, dass Tracker-Tools Folgendes untersuchen können http://svn/Projects/CashCowProject und ALLE Aktivitäten zu diesem Projekt sehen, aber keine Aktivitäten zu anderen Projekten. Außerdem zwingt es Sie dazu, Verweise zwischen Projekten zu kontrollieren, was bedeutet, dass sich Ihre Top-Level-Projekte nicht ohne einen Eintrag in trunk ändern.

Wenn Projekte aufeinander verweisen, verwenden Sie svn:externals, um ein Tag aus dem benötigten Bibliotheksprojekt zu ziehen. Verwenden Sie Vendor Branches, wie im red-bean Buch beschrieben, um Bibliotheken von Drittanbietern zu behandeln, sogar Binärdateien.

Die Aufbewahrung von Bibliotheks-Binärdateien in SVN ist in Ordnung. Man sollte vielleicht ein separates Repository dafür in Betracht ziehen, obwohl wir das nicht tun.

Für die Code-Promotion sollten Sie einen stabilen Zweig für eine bestimmte Version behalten und immer nur vom Stamm in diesen Zweig zusammenführen und dann von diesem Zweig aus markieren. So erhalten Sie eine überprüfbare Aufzeichnung dessen, was in jeder Version enthalten ist.

Sie können COM-Binärdateien darin aufbewahren, wenn Sie den Quellcode nicht einlesen und bauen wollen. Sie können ein Post-Upgrade-Skript für Tortoise schreiben, das alle COM-Objekte registriert, die es findet.