Best Practice mit verzweigtem Quellcode und Anwendungslebenszyklus

Wir sind ein kleiner ISV-Shop und versenden normalerweise jeden Monat eine neue Version unserer Produkte. Wir verwenden Subversion als Code-Repository und Visual Studio 2010 als IDE. Ich bin mir bewusst, dass viele Leute Mercurial und andere verteilte Versionsverwaltungssysteme befürworten, aber an diesem Punkt sehe ich nicht, wie wir davon profitieren könnten, aber ich könnte mich irren.

Unser Hauptproblem ist, wie Zweige und Hauptstamm synchron bleiben.

So machen wir es heute:

1. Neue Version freigeben (automatisch ein Tag in Subversion erstellen)
2. Arbeiten Sie weiter an der Hauptleitung, die nächsten Monat veröffentlicht wird

Und der Zyklus wiederholt sich jeden Monat und funktioniert perfekt. Das Problem tritt auf, wenn eine dringende Servicefreigabe freigegeben werden muss. Wir können es nicht aus dem Hauptstamm (2) lösen, da es sich in einer starken Entwicklung befindet und nicht stabil genug ist, um dringend freigegeben zu werden.

In diesem Fall machen wir Folgendes:

1. Erstellen Sie einen Zweig aus dem Tag, das wir in Schritt (1) erstellt haben.
2. Fehlerbehebung
3. Testen und freigeben
4. Schieben Sie das Wechselgeld zurück in den Hauptkoffer (falls zutreffend).

Unser größtes Problem ist die Zusammenführung dieser beiden (Zweig mit Haupt). In den meisten Fällen können wir uns nicht auf die automatische Zusammenführung verlassen, weil z.

• Es wurden viele Änderungen am Hauptstamm vorgenommen
• Das Zusammenführen komplexer Dateien (wie Visual Studio XML-Dateien usw.) funktioniert nicht sehr gut
• Ein anderer Entwickler / ein anderes Team hat Änderungen vorgenommen, die Sie nicht verstehen und die Sie nicht einfach zusammenführen können

Was Sie also denken, ist die beste Vorgehensweise, um diese beiden unterschiedlichen Versionen (Zweig und Haupt) synchron zu halten. Wie geht's?

Ich denke, Ihr Ansatz zum Verzweigen und Zusammenführen ist in Ordnung, aber wenn das Hauptproblem darin besteht, dass die Codebasis ziemlich instabil ist, müssen Sie sich darauf konzentrieren und diese minimieren.

In erster Linie muss sichergestellt werden, dass die Codebasis eine gute Trennung der Bedenken aufweist . Abhängigkeiten zwischen verschiedenen Komponenten müssen isoliert und reduziert werden. Dies sollte die meisten Ihrer Probleme lösen. Auch das Befolgen von Praktiken wie dem Prinzip der Einzelverantwortung wird helfen.

Wenn eine größere architektonische Änderung erforderlich ist, sollte diese in einem eigenen Zweig stattfinden und dann nach vollständiger Prüfung und „Stabilität“ (im Rahmen des Zumutbaren) wieder in den Hauptzweig integriert werden. Dies kann schmerzhaft und herausfordernd sein, sollte aber auch selten sein. Wenn Sie über gute Testpraktiken verfügen, wird das Risiko minimiert.

Es kann auch hilfreich sein, auf ein verteiltes Versionskontrollsystem umzusteigen. Dies sollte Ihnen einen stabilen Stamm geben, in dem verschiedene Funktionen aus verschiedenen Zweigen zusammengeführt werden, wenn sie bereit sind. Sie werden immer noch Schmerzen beim Zusammenführen haben, wenn der Code zu stark voneinander abhängig ist, aber Sie haben mehr Kontrolle.

Wenn Sie dies aus einer anderen Perspektive betrachten, sollten Sie auch eine verbesserte Kommunikation zwischen Ihrem Team in Betracht ziehen. Führen Sie regelmäßig Standup-Meetings im agilen Stil durch. Überlegen Sie, wo die Teammitglieder sitzen und wie dies helfen kann. Wenn eine komplexe Zusammenführung stattfinden muss, ist dies möglicherweise nicht so schlimm. Verwenden Sie einen Paarprogrammierungsansatz, der beiden Parteien Verständnis vermittelt.

Ich neige dazu, es so ziemlich umgekehrt zu betrachten:

• Trunk sollte immer produktionsbereiter Code sein (dh nach Ihrer ersten Erstveröffentlichung).
• Es sollte einen Entwicklungszweig geben, der parallel zum Trunk läuft, in dem Ihre monatliche Entwicklung stattfindet. Jeden Monat, wenn es um die Veröffentlichungszeit geht, wird diese in den Trunk integriert, getestet und dann freigegeben.
• Hotfixes können dann einfach in Ihrem Trunk erstellt und eingecheckt werden und immer erfolgreich bereitgestellt werden. Erstellen Sie dann einen Patch aus dem Hotfix und wenden Sie ihn auf Ihren Entwicklungszweig an.

Natürlich eignet sich dieser Workflow viel besser für etwas, das kein SVN ist, da eine gute Verzweigung und Zusammenführung in SVN unabhängig von Ihrem Workflow sehr schmerzhaft ist. Nach meiner Erfahrung sollte das Zusammenführen in SVN fast immer manuell erfolgen, da es einfach nicht funktioniert und es keinen wirklichen Weg gibt, dies zu umgehen.

In letzter Zeit habe ich mich als letztes Ergebnis für eine Philosophie von "Branch and Merge" ausgesprochen. Ich denke, es ist die unglückliche Wahrheit, dass der Umgang mit Code, der aus Zweigen zusammengeführt wird, kein technisches Problem ist, aber es ist eine kognitiv schwierige Aufgabe: Ich denke, es ist einfach so, dass das menschliche Gehirn nicht genügend Details verfolgt, um es einfach zu machen. Darüber hinaus habe ich noch nicht gesehen, dass das Verzweigen und Zusammenführen in der Praxis tatsächlich funktioniert. Sobald der Code verzweigt ist, zeigt mir die Erfahrung, dass es nichts anderes als Probleme ist, ihn erneut zusammenzuführen.

Ein disziplinierter Release-on-Main-Ansatz funktioniert gut.

Die SVN-Verzweigung ist nicht flexibel ausgelegt. Ich würde vorschlagen, dass Ihr erstes Problem in SVN liegt. Wenn Sie sich davon entfernen, eröffnen sich neue Optionen.