Wie pflegen Sie den Entwicklungscode und den Produktionscode?

Question

Was sind die besten Praktiken und Faustregeln, die bei der Pflege des Codes zu beachten sind? Ist es eine gute Praxis, nur den produktionsreifen Code im Entwicklungszweig zu haben, oder sollte der neueste, nicht getestete Code im Entwicklungszweig verfügbar sein?

Wie pflegt ihr euren Entwicklungscode und euren Produktionscode?

Bearbeiten - Zusatzfrage - Folgt Ihr Entwicklungsteam dem "Commit-as-so soon as-possible-and-often-even-ifif-the-code-contains-minor-bugs-or-is-incomplete"-Protokoll oder dem "Commit-ONLY-perfect-code"-Protokoll bei der Übergabe von Code an den DEVELOPMENT-Zweig?

Answer 1

Update 2019:

Heutzutage würde die Frage in einem Kontext gesehen werden, in dem Git verwendet wird, und 10 Jahre der Verwendung dieses verteilt Entwicklung Arbeitsablauf (Zusammenarbeit hauptsächlich mit über GitHub ) zeigt die allgemein besten Praktiken:

• master ist der Zweig, der jederzeit in der Produktion eingesetzt werden kann: die nächste Version mit einer ausgewählten Reihe von Funktionszweigen, die in master .
• dev (oder Integrationszweig, oder ' next ') ist diejenige, in der die für die nächste Version ausgewählten Funktionszweige gemeinsam getestet werden
• maintenance (ou hot-fix ) ist der Zweig, in dem die aktuelle Version entwickelt und Fehler behoben werden, mit möglichen Übergängen zurück zu dev und oder master

Diese Art von Arbeitsablauf (bei dem man nicht dev a master aber wo Sie nur den Funktionszweig nach dev und dann, falls ausgewählt, auf master (um Funktionszweige, die nicht für die nächste Version bereit sind, einfach löschen zu können) ist im Git-Repository selbst implementiert, mit der gitworkflow (ein Wort, hier abgebildet ).
Siehe mehr unter rocketraman/gitworkflow . Die Geschichte dieses Vorgehens gegenüber der stammesbasierten Entwicklung ist in den Kommentaren und Diskussionen von dieser Artikel von Adam Dymitruk .

(Quelle: Gitworkflow: Ein aufgabenorientierter Leitfaden )

Hinweis: In diesem verteilten Arbeitsablauf können Sie jederzeit Commits vornehmen und WIP (Work In Progress) ohne Probleme in einen persönlichen Zweig verschieben: Sie können Ihre Commits reorganisieren (git rebase), bevor Sie sie in einen Feature-Zweig einbinden.

---

Originalantwort (Okt. 2008, vor 10+ Jahren)

Es hängt alles von der die sequentielle Natur Ihres Release-Managements

Erstens, ist alles in Ihrem Kofferraum wirklich für die nächste Version ? Sie werden feststellen, dass einige der derzeit entwickelten Funktionen folgende sind:

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

In diesem Fall sollte der Stamm alle laufenden Entwicklungsarbeiten enthalten, aber ein früh vor der nächsten Version definierter Versionszweig kann als Konsolidierungsstelle bei dem nur der geeignete (für die nächste Version validierte) Code zusammengeführt, dann während der Homologationsphase korrigiert und schließlich bei der Produktion eingefroren wird.

Wenn es um Produktionscode geht, müssen Sie auch Ihre Patch-Zweige wobei zu beachten ist, dass:

• der erste Satz von Patches könnte bereits vor der ersten Produktionsfreigabe beginnen (d.h. 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 an diesen Fehlern in einem separaten Zweig beginnen)
• die anderen Patch-Zweige werden den Luxus haben, von einem genau definierten Produktionslabel auszugehen

Wenn es um den Entwicklungszweig geht, können Sie einen Stamm haben, es sei denn, Sie haben andere Entwicklungsarbeiten, die Sie durchführen müssen parallel dazu mögen:

• massives Refactoring
• Testen einer neuen technischen Bibliothek, die die Art und Weise, wie Sie Dinge in anderen Klassen aufrufen, verändern könnte
• Beginn eines neuen Release-Zyklus, in den wichtige architektonische Änderungen eingearbeitet werden müssen.

Wenn Ihr Entwicklungs- und Veröffentlichungszyklus sehr sequentiell ist, können Sie einfach so vorgehen, wie es die anderen Antworten vorschlagen: ein Stamm und mehrere Veröffentlichungszweige. Das funktioniert für kleine Projekte, bei denen die gesamte Entwicklung sicher in die nächste Version einfließt, und kann einfach eingefroren werden und als Ausgangspunkt für den Versionszweig dienen, wo Patches stattfinden können. Das ist der nominelle Prozess, aber sobald Sie ein komplexeres Projekt haben... ist es nicht mehr genug.

---

Um den Kommentar von Ville M. zu beantworten:

• Denken Sie daran, dass "dev branch" nicht "ein Zweig pro Entwickler" bedeutet (was den "Merge-Wahnsinn" auslösen würde, da jeder Entwickler die Arbeit der anderen zusammenführen müsste, um deren Arbeit zu sehen/zu bekommen), sondern ein dev branch pro Entwicklungsaufwand.
• Wenn diese Arbeiten in den Stamm (oder einen anderen von Ihnen definierten "Haupt-" oder Versionszweig) zurückgeführt werden müssen, ist dies die Arbeit des Entwicklers, no - Ich wiederhole, NICHT - der SC-Manager (der nicht weiß, wie er einen Konflikt lösen soll). Der Projektleiter kann die Zusammenführung beaufsichtigen, d. h. dafür sorgen, dass sie rechtzeitig beginnt/beendet wird.
• wen auch immer Sie für die Zusammenführung wählen, das Wichtigste ist:
  • um Unit-Tests und/oder eine Assembly-Umgebung zu haben, in der Sie das Ergebnis der Zusammenführung bereitstellen/prüfen können.
  • einen Tag definiert zu haben antes de zu Beginn der Zusammenführung, um zum vorherigen Zustand zurückkehren zu können, wenn sich die Zusammenführung als zu komplex oder zu langwierig erweist.

Answer 2

Wir verwenden:

• Entwicklungsbereich ausschließlich

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

• Freigabezweig

Es werden keine neuen Funktionen in den Release-Zweig aufgenommen. Nur wichtige Fehler werden im Veröffentlichungszweig behoben, und der Code zur Behebung dieser Fehler wird wieder in den Entwicklungszweig integriert.

Der zweiteilige Prozess mit einem Entwicklungs- und einem stabilen (Release-)Zweig macht uns das Leben sehr viel leichter, und ich glaube nicht, dass wir irgendetwas davon durch die Einführung weiterer Zweige verbessern könnten. Jeder Zweig hat auch seinen eigenen Erstellungsprozess, was bedeutet, dass alle paar Minuten ein neuer Erstellungsprozess gestartet wird, so dass wir nach einem Code-Checkin innerhalb von etwa einer halben Stunde eine neue ausführbare Datei mit allen Erstellungsversionen und Zweigen haben.

Gelegentlich haben wir auch Zweigstellen für einen einzelnen Entwickler, der an einer neuen, noch nicht erprobten Technologie arbeitet oder ein Proof of Concept erstellt. Aber im Allgemeinen wird das nur gemacht, wenn die Änderungen viele Teile der Codebasis betreffen. Dies geschieht im Durchschnitt alle 3-4 Monate, und ein solcher Zweig wird normalerweise innerhalb von ein oder zwei Monaten wieder integriert (oder verworfen).

Generell gefällt mir die Idee nicht, dass jeder Entwickler in seinem eigenen Zweig arbeitet, weil man sich dann direkt in die "Integrationshölle" begibt. Davon würde ich dringend abraten. Wenn Sie eine gemeinsame Codebasis haben, sollten Sie alle gemeinsam daran arbeiten. Dadurch werden die Entwickler vorsichtiger, was ihre Checkins angeht, und mit der Erfahrung weiß jeder Entwickler, welche Änderungen möglicherweise den Build zerstören, so dass die Tests in solchen Fällen strenger sind.

Zur Frage des frühen Eincheckens:

Wenn Sie nur PERFEKTER CODE eingecheckt werden soll, dann sollte eigentlich nichts eingecheckt werden. Kein Code ist perfekt, und damit die Qualitätssicherung ihn verifizieren und testen kann, muss er im Entwicklungszweig sein, damit eine neue ausführbare Datei erstellt werden kann.

Für uns bedeutet das, dass eine Funktion, sobald sie fertiggestellt und vom Entwickler getestet ist, eingecheckt wird. Es kann sogar eingecheckt werden, wenn es bekannte (nicht fatale) Fehler gibt, aber in diesem Fall werden die Personen, die von dem Fehler betroffen wären, normalerweise informiert. Unvollständiger und in Arbeit befindlicher Code kann ebenfalls eingecheckt werden, aber nur, wenn er keine offensichtlichen negativen Auswirkungen hat, wie Abstürze oder das Aufbrechen bestehender Funktionen.

Hin und wieder macht ein unvermeidlicher kombinierter Code- und Daten-Checkin das Programm unbrauchbar, bis der neue Code erstellt ist. Das Mindeste, was wir tun, ist, einen "WAIT FOR BUILD"-Vermerk in den Check-in-Kommentar einzufügen und/oder eine E-Mail zu versenden.

Answer 3

Wir gehen dabei folgendermaßen vor.

Die meiste Entwicklung wird im Stamm durchgeführt, obwohl experimentelle Features oder Dinge, die das System signifikant verändern könnten, dazu neigen, ihren eigenen Zweig zu bekommen. Das funktioniert ziemlich gut, da es bedeutet, dass jeder Entwickler immer die neueste Version von allem in seiner Arbeitskopie hat.

Das bedeutet, dass es wichtig ist, den Kofferraum in einem einigermaßen funktionstüchtigen Zustand zu halten, denn es ist durchaus möglich, dass er komplett kaputt geht. In der Praxis kommt das nicht oft vor und ist selten ein großes Problem.

Bei einer Produktionsveröffentlichung verzweigen wir den Stamm, fügen keine neuen Funktionen mehr hinzu und arbeiten an der Fehlerbehebung und dem Testen des Zweigs (und fügen ihn regelmäßig wieder in den Stamm ein), bis er für die Veröffentlichung bereit ist. Zu diesem Zeitpunkt führen wir einen abschließenden Merge in den Stamm durch, um sicherzustellen, dass alles da ist, und veröffentlichen dann.

Die Wartungsarbeiten können dann bei Bedarf im Versionszweig durchgeführt werden, und diese Korrekturen können leicht wieder in den Stamm eingebunden werden.

Ich behaupte nicht, dass dies ein perfektes System ist (und es hat immer noch einige Lücken - ich glaube nicht, dass unser Freigabemanagement ein ausreichend straffer Prozess ist), aber es funktioniert gut genug.

Answer 4

Warum wird das nicht mehr erwähnt? Ein erfolgreiches Git-Verzweigungsmodell .

Das ist für mich das ultimative Verzweigungsmodell!

Wenn Ihr Projekt klein ist, verwenden Sie nicht ständig alle verschiedenen Zweige (vielleicht können Sie Feature-Zweige für kleine Features auslassen). Aber ansonsten ist das der richtige Weg!

Answer 5

Entwicklungscode auf Zweigen, Live-Code auf dem Trunk markiert.

Es muss keine Regel geben, die besagt, dass nur perfekter Code übertragen werden darf - alles, was der Entwickler übersieht, sollte an vier Stellen aufgegriffen werden: bei der Codeüberprüfung, beim Testen der Zweige, beim Regressionstest und beim abschließenden QA-Test.

Hier finden Sie eine detaillierte Schritt-für-Schritt-Erklärung:

1. Führen Sie die gesamte Entwicklung auf einem Zweig durch und nehmen Sie dabei regelmäßig Übertragungen vor.
2. Unabhängige Codeüberprüfung der Änderungen nach Abschluss der gesamten Entwicklung.
3. Übergeben Sie dann den Zweig an den Test.
4. Sobald die Tests des Zweigs abgeschlossen sind, führen Sie den Code in den Zweig "Release Candidate" ein.
5. Der Release Candidate-Zweig wird nach jedem einzelnen Merge einem Regressionstest unterzogen.
6. Abschließende QA- und UA-Tests werden auf RC durchgeführt, nachdem alle Entwicklungszweige zusammengeführt wurden.
7. Sobald QA und UAT bestanden sind, wird der Release-Zweig mit dem MAIN/TRUNK-Zweig zusammengeführt.
8. Abschließend markieren Sie den Trunk an diesem Punkt und verteilen das Tag an Live.