Wie pflegen Sie Entwicklungscode und Produktionscode? [geschlossen]

Welche Best Practices und Faustregeln sind bei der Pflege des Codes zu beachten? Ist es empfehlenswert, nur den produktionsbereiten Code im Entwicklungszweig zu haben, oder sollte ungetesteter aktueller Code im Entwicklungszweig verfügbar sein?

Wie pflegen Sie Ihren Entwicklungscode und Produktionscode?

Bearbeiten - Ergänzende Frage - Befolgt Ihr Entwicklungsteam das Protokoll "Festschreiben so bald wie möglich und oft sogar, wenn der Code kleinere Fehler enthält oder unvollständig ist" oder "Festschreiben"? NUR-Perfect-Code "-Protokoll beim Festschreiben von Code an den DEVELOPMENT-Zweig?

Update 2019:

In diesen Tagen würden die Frage in einem Zusammenhang zu sehen mit Git und 10 Jahren mit , dass verteilte Entwicklung Workflow ( die Zusammenarbeit vor allem durch GitHub ) zeigen die allgemeine Best Practices:

• masterIst der Zweig jederzeit einsatzbereit für die Produktion: In der nächsten Version werden ausgewählte Feature-Zweige zusammengeführt master.
• dev(oder Integrationszweig oder ' next') ist derjenige, in dem der für die nächste Version ausgewählte Feature-Zweig zusammen getestet wird
• maintenance(oder hot-fix) Zweig ist derjenige für die aktuelle Release-Entwicklung / Fehlerbehebungen mit möglichen Zusammenführungen zurück zu devund odermaster

Diese Art von Workflow (wo Sie verschmelzen nicht devzu master, aber wo man nur Zweig zu fusionieren dev, dann , wenn ausgewählt, auf master, um in der Lage zu sein , leicht verfügt über Filialen nicht bereit für die nächste Version fallen) im Git implementiert Repo selbst, mit dem Gitworkflow (ein Wort, hier abgebildet ).
Weitere Informationen finden Sie unter rocketraman/gitworkflow. Die Geschichte dieses Vorgehens im Vergleich zu Trunk-Based-Development wird in den Kommentaren und Diskussionen dieses Artikels von Adam Dymitruk erwähnt .

^{(Quelle: Gitworkflow: Ein aufgabenorientierter Primer )}

Hinweis: In diesem verteilten Workflow können Sie jederzeit Commits durchführen und WIP (Work In Progress) ohne Probleme an einen persönlichen Zweig senden: Sie können Ihre Commits neu organisieren (git rebase), bevor Sie sie zu einem Teil eines Feature-Zweigs machen.

Ursprüngliche Antwort (Okt. 2008, vor mehr als 10 Jahren)

Es hängt alles von der Reihenfolge Ihres Release-Managements ab

Erstens, ist wirklich alles in Ihrem Kofferraum für die nächste Veröffentlichung ? Möglicherweise stellen Sie fest, dass einige der derzeit entwickelten Funktionen:

• zu kompliziert und müssen noch verfeinert werden
• nicht rechtzeitig fertig
• interessant, aber nicht für diese nächste Veröffentlichung

In diesem Fall sollte Trunk alle aktuellen Entwicklungsbemühungen enthalten, aber ein Release-Zweig, der früh vor dem nächsten Release definiert wurde, kann als Konsolidierungszweig dienen , in dem nur der entsprechende Code (validiert für das nächste Release) zusammengeführt und dann während der Homologationsphase repariert wird. und schließlich eingefroren, wenn es in Produktion geht.

Wenn es um Produktionscode geht, müssen Sie auch Ihre Patch-Zweige verwalten und dabei Folgendes berücksichtigen:

• Der erste Satz von Patches beginnt möglicherweise tatsächlich vor der ersten Veröffentlichung in der Produktion (was bedeutet, dass Sie wissen, dass Sie mit einigen Fehlern in die Produktion gehen werden, die Sie nicht rechtzeitig beheben können, aber Sie können die Arbeit für diese Fehler in einem separaten Zweig einleiten).
• Die anderen Patch-Filialen werden den Luxus haben, von einem genau definierten Produktionslabel auszugehen

Wenn es um Entwicklungszweige geht, können Sie einen Trunk haben, es sei denn, Sie müssen andere Entwicklungsanstrengungen unternehmen parallel wie:

• massives Refactoring
• Testen einer neuen technischen Bibliothek, die möglicherweise die Art und Weise ändert, wie Sie Dinge in anderen Klassen aufrufen
• Beginn eines neuen Release-Zyklus, in dem wichtige architektonische Änderungen berücksichtigt werden müssen.

Wenn Ihr Entwicklungs-Release-Zyklus sehr sequentiell ist, können Sie einfach so vorgehen, wie die anderen Antworten vermuten lassen: ein Trunk und mehrere Release-Zweige. Dies funktioniert für kleine Projekte, bei denen die gesamte Entwicklung sicher in die nächste Version übergeht, und kann einfach eingefroren werden und als Ausgangspunkt für den Release-Zweig dienen, in dem Patches stattfinden können. Das ist der nominelle Prozess, aber sobald Sie ein komplexeres Projekt haben ... reicht es nicht mehr aus.

Um den Kommentar von Ville M. zu beantworten:

• Denken Sie daran, dass Dev-Zweig nicht "ein Zweig pro Entwickler" bedeutet (was "Merge Madness" auslösen würde, da jeder Entwickler die Arbeit eines anderen zusammenführen müsste, um seine Arbeit zu sehen / zu erhalten), sondern einen Dev-Zweig pro Entwicklung Anstrengung.
• Wenn diese Bemühungen wieder in Trunk (oder einem anderen von Ihnen definierten "Haupt" - oder Release-Zweig) zusammengeführt werden müssen, ist dies die Arbeit des Entwicklers, nicht - ich wiederhole, NICHT - des SC-Managers (der nicht wissen würde, wie er zu lösen ist) jede widersprüchliche Zusammenführung). Der Projektleiter kann die Zusammenführung überwachen, dh sicherstellen, dass sie pünktlich beginnt / endet.
• Wer auch immer Sie für die eigentliche Zusammenführung auswählen, das Wichtigste ist:
  • Unit-Tests und / oder Assembly-Umgebungen, in denen Sie das Ergebnis der Zusammenführung bereitstellen / testen können.
  • vor Beginn der Zusammenführung ein Tag definiert zu haben , um zum vorherigen Zustand zurückkehren zu können, wenn sich die Zusammenführung als zu komplex oder zu lang zum Auflösen erweist.

Wir gebrauchen:

• Entwicklungszweig ausschließlich

Bis das Projekt kurz vor dem Abschluss steht oder wir eine Meilensteinversion erstellen (z. B. Produktdemo, Präsentationsversion), verzweigen wir (regelmäßig) unseren aktuellen Entwicklungszweig in:

• Zweig freigeben

In den Release-Zweig gehen keine neuen Funktionen. Im Release-Zweig werden nur wichtige Fehler behoben, und der Code zum Beheben dieser Fehler wird wieder in den Entwicklungszweig integriert.

Der zweiteilige Prozess mit einer Entwicklung und einem stabilen (Release-) Zweig erleichtert uns das Leben erheblich, und ich glaube nicht, dass wir einen Teil davon verbessern könnten, indem wir mehr Zweige einführen. Jeder Zweig hat auch einen eigenen Erstellungsprozess, dh alle paar Minuten wird ein neuer Erstellungsprozess erstellt. Nach dem Einchecken des Codes haben wir innerhalb einer halben Stunde eine neue ausführbare Datei aller Erstellungsversionen und Zweige.

Gelegentlich haben wir auch Niederlassungen für einen einzelnen Entwickler, der an einer neuen und nicht bewährten Technologie arbeitet oder einen Proof of Concept erstellt. Im Allgemeinen wird dies jedoch nur durchgeführt, wenn die Änderungen viele Teile der Codebasis betreffen. Dies geschieht durchschnittlich alle 3-4 Monate, und ein solcher Zweig wird normalerweise innerhalb von ein oder zwei Monaten wieder integriert (oder verschrottet).

Im Allgemeinen mag ich nicht die Idee, dass jeder Entwickler in seiner eigenen Branche arbeitet, weil Sie "überspringen und direkt zur Integrationshölle gehen". Ich würde dringend davon abraten. Wenn Sie eine gemeinsame Codebasis haben, sollten Sie alle zusammenarbeiten. Dies macht Entwickler bei ihren Checkins vorsichtiger, und mit der Erfahrung weiß jeder Codierer, welche Änderungen den Build möglicherweise beschädigen. Daher sind die Tests in solchen Fällen strenger.

Bei der Check-in-Frühfrage:

Wenn nur PERFEKTER CODE eingecheckt werden muss, sollte eigentlich nichts eingecheckt werden. Kein Code ist perfekt. Damit die Qualitätssicherung ihn überprüfen und testen kann, muss er sich im Entwicklungszweig befinden, damit eine neue ausführbare Datei erstellt werden kann.

Für uns bedeutet dies, dass eine Funktion, sobald sie vom Entwickler abgeschlossen und getestet wurde, eingecheckt ist. Sie kann sogar eingecheckt werden, wenn bekannte (nicht schwerwiegende) Fehler vorliegen. In diesem Fall sind es jedoch die Personen, die von dem Fehler betroffen wären in der Regel informiert. Unvollständiger und in Arbeit befindlicher Code kann ebenfalls eingecheckt werden, jedoch nur, wenn er keine offensichtlichen negativen Auswirkungen wie Abstürze oder Unterbrechungen vorhandener Funktionen verursacht.

Hin und wieder macht ein unvermeidbares kombiniertes Einchecken von Code und Daten das Programm unbrauchbar, bis der neue Code erstellt wurde. Das Mindeste, was wir tun, ist, im Check-in-Kommentar ein "WAIT FOR BUILD" hinzuzufügen und / oder eine E-Mail zu senden.

Für das, was es wert ist, machen wir es so.

Der größte Teil der Entwicklung wird im Trunk durchgeführt, obwohl experimentelle Funktionen oder Dinge, die das System erheblich beschädigen könnten, dazu neigen, einen eigenen Zweig zu erhalten. Dies funktioniert ziemlich gut, da jeder Entwickler immer die neueste Version von allem in seiner Arbeitskopie hat.

Es bedeutet jedoch, dass es wichtig ist, den Kofferraum in einem vagen Zustand zu halten, da es durchaus möglich ist, ihn vollständig zu zerbrechen. In der Praxis kommt das nicht oft vor und ist selten ein bedeutendes Problem.

Bei einer Produktionsversion verzweigen wir Trunk, fügen keine neuen Funktionen mehr hinzu und arbeiten daran, den Zweig zu beheben und zu testen (regelmäßig wieder in Trunk zusammenzuführen), bis er zur Veröffentlichung bereit ist. An diesem Punkt führen wir eine endgültige Zusammenführung in den Trunk durch, um sicherzustellen, dass sich alles darin befindet, und geben dann frei.

Die Wartung kann dann bei Bedarf am Release-Zweig durchgeführt werden, und diese Korrekturen können problemlos wieder in den Trunk integriert werden.

Ich behaupte nicht, dass dies ein perfektes System ist (und es hat immer noch einige Lücken - ich denke, unser Release-Management ist noch nicht eng genug), aber es funktioniert gut genug.

Warum erwähnt das noch niemand? Ein erfolgreiches Git-Verzweigungsmodell .

Es ist für mich das ultimative Verzweigungsmodell!

Wenn Ihr Projekt klein ist, verwenden Sie nicht immer alle verschiedenen Zweige (möglicherweise können Sie Feature-Zweige für kleine Features überspringen). Aber sonst ist es der Weg, es zu tun!

Entwicklungscode für Zweige, Live-Code für Trunk.

Es muss keine Regel "Nur perfekten Code festschreiben" geben - alles, was der Entwickler vermisst, sollte an vier Stellen aufgegriffen werden: Codeüberprüfung, Verzweigungstest, Regressionstest, endgültiger QS-Test.

Hier ist eine detailliertere schrittweise Erklärung:

1. Führen Sie die gesamte Entwicklung in einem Zweig durch und verpflichten Sie sich regelmäßig.
2. Unabhängiger Code Überprüfung der Änderungen, sobald alle Entwicklungen abgeschlossen sind.
3. Übergeben Sie dann den Zweig an Testing.
4. Sobald der Branchentest abgeschlossen ist, führen Sie den Code in den Release Candidate-Zweig ein.
5. Der Release Candidate-Zweig wird nach jeder einzelnen Zusammenführung einer Regressionstest unterzogen.
6. Die endgültigen QS- und UA-Tests wurden an RC durchgeführt, nachdem alle Entwicklungszweige zusammengeführt wurden.
7. Sobald QA und UAT übergeben wurden, führen Sie den Release-Zweig in den MAIN / TRUNK-Zweig ein.
8. Markieren Sie schließlich den Trunk an diesem Punkt und stellen Sie dieses Tag für Live bereit.

dev geht in den Trunk (SVN-Stil) und Releases (Produktionscode) bekommen ihre eigenen Zweige

Es ist das "Branch-by-Purpose-Modell" (Abbildung 3 in Die Bedeutung von Verzweigungsmodellen /! \ Pdf)

Wir lösen dieses Problem, indem wir den Produktionscode (den Hauptstamm) vollständig vom Entwicklungscode trennen (wobei jeder Entwickler seinen eigenen Zweig hat).

In den Produktionscode darf kein Code aufgenommen werden, bevor er gründlich überprüft wurde (von der Qualitätssicherung und den Codeprüfern).

Auf diese Weise gibt es keine Verwirrung darüber, welcher Code funktioniert, es ist immer der Hauptzweig.

Oh ja - eine andere Sache - wir behalten Nicht-Produktionscode (dh den, der NIEMALS veröffentlicht wird - z. B. Toolskripte, Testdienstprogramme) in cvs HEAD. Normalerweise muss es deutlich gekennzeichnet sein, damit niemand es "versehentlich" freigibt.

Wir entwickeln auf Stamm, der dann alle zwei Wochen verzweigt und in Produktion geht. In der Filiale werden nur kritische Fehler behoben, der Rest kann weitere zwei Wochen warten.

Für Trunk lautet die einzige Regel, dass ein Commit nichts beschädigen sollte. Um Wip-Code und nicht getesteten Code zu verwalten, fügen wir einfach geeignete if-Anweisungen hinzu, um das Ein- und Ausschalten zu vereinfachen.

Grundsätzlich wäre es möglich, den Stamm jederzeit zu verzweigen und in Produktion zu bringen.

Ich benutze Git und habe 2 Zweige: Master und Maint

• Master - Entwicklungscode
• Wartungscode

Wenn ich Code für die Produktion freigebe , tagge ich ihn und füge Master zu Main Branch zusammen. Ich stelle immer von der Hauptniederlassung aus bereit . Patches aus dem Entwicklungszweig Ich wähle sie aus, um den Zweig zu pflegen und Patches bereitzustellen.

Wir haben einen "Release" -Zweig, der enthält, was gerade produziert wird oder in Kürze bereitgestellt wird (die meisten Qualitätssicherungen wurden bereits bestanden).

Jedes Projekt oder in einigen Fällen eine andere Einheit hat eine eigene Verzweigung, die ab der Veröffentlichung verzweigt ist.

Änderungen werden von den Entwicklern des Projekts in den eigenen Zweig ihres Projekts übernommen. In regelmäßigen Abständen wird die Freigabe wieder in einem Entwicklungszweig zusammengeführt.

Sobald alle Arbeitspakete in der Verzweigung QS-geprüft sind (Komponententest, Systemtest, Codeüberprüfung, QA-Überprüfung usw.), wird die Verzweigung in der Freigabezweig zusammengeführt. Die neuen Builds werden aus dem Release-Zweig erstellt, und die endgültige Validierung erfolgt für diese Version.

Der Vorgang ist grundsätzlich in Ordnung, bis nach einer Zusammenführung ein Problem entdeckt wird. Wenn ein WP nach dem Zusammenführen "stecken bleibt", hält es alles danach auf, bis es repariert ist (wir können keine weitere Veröffentlichung durchführen, bis die feststeckende Version veröffentlicht wird).

Es ist auch etwas flexibel - eine sehr triviale Änderung könnte direkt im Release-Zweig auftreten, wenn es in einem sehr kurzen Zeitraum (wie 1-2 Tage oder so) veröffentlicht wird.

Wenn eine Änderung aus irgendeinem Grund direkt in die Produktion übernommen wurde (ein kritisches kundenbeeinflussendes Produktionsproblem, für dessen Behebung eine sofortige Codeänderung erforderlich war), werden diese Änderungen in BRANCH_RELEASE zurückgesetzt. Das passiert kaum.

Das hängt vom Projekt ab. Unser Webcode wird ziemlich konsistent eingecheckt, während unser Anwendungscode nur eingecheckt wird, wenn er kompiliert wird. Mir ist aufgefallen, dass dies ziemlich ähnlich ist, wie wir Dinge veröffentlichen. Web-Inhalte werden immer dann angezeigt, wenn Anwendungen eine harte Frist erreichen. Bei beiden Methoden habe ich jedoch keinen Qualitätsverlust festgestellt.