it-swarm.com.de

Wie pflegen Sie Entwicklungscode und Produktionscode?

Welche Best Practices und Faustregeln sollten bei der Pflege des Codes befolgt werden? Ist es empfehlenswert, nur den produktionsbereiten Code im Entwicklungszweig zu haben, oder sollte nicht getesteter aktueller Code im Entwicklungszweig verfügbar sein?

Wie pflegt ihr euren Entwicklungs- und Produktionscode?

Bearbeiten - Ergänzende Frage - Befolgt Ihr Entwicklungsteam das Protokoll "Festschreiben, sobald es möglich und oftmals sogar dann, wenn der Code geringfügige Fehler enthält oder unvollständig ist" oder "Festschreiben"? ONLY-perfect-code "-Protokoll beim Festschreiben des Codes in der DEVELOPMENT-Branche?

131
Mohit Ranka

Update 2019:

Heutzutage wird die Frage in einem Kontext mit Git gesehen, und 10 Jahre mit dieser verteilten Entwicklung Workflow (hauptsächlich zusammenarbeiten über GitHub ) zeigt die allgemeinen Best Practices:

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

Diese Art von Workflow (bei dem Sie nicht dev mit master zusammenführen, sondern nur den Objektzweig mit dev zusammenführen und, falls ausgewählt, mit master, um Feature-Verzweigungen, die nicht für das nächste Release bereit sind, einfach löschen zu können) ist im Git-Repo selbst implementiert, mit dem gitworkflow ( ein Wort, hier dargestellt ).
Mehr unter rocketraman/gitworkflow .

https://github.com/rocketraman/gitworkflow/raw/master/docs/images/topicgraduation.png

(Quelle: Gitworkflow: A Task-Oriented Primer )

Hinweis: In diesem verteilten Workflow können Sie ein Commit ausführen, wann immer Sie möchten, und ohne Probleme WIP (Work In Progress) 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 (vor Okt. 2008, 10+ Jahren)

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

Ist erstens alles in deinem Kofferraum wirklich 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 vor dem nächsten Release definiert wurde, kann als Konsolidierungszweig dienen, in dem Nur der entsprechende Code (validiert für die nächste Version) wird zusammengeführt, dann während der Homologationsphase behoben und schließlich eingefroren, wenn er in Produktion geht.

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

  • der erste Satz von Patches kann tatsächlich vor der ersten Veröffentlichung in der Produktion beginnen (dh 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 beginnen).
  • die anderen Patch-Filialen werden den Luxus haben, von einem genau definierten Produktionslabel auszugehen

Wenn es um Dev Branch geht, können Sie einen Trunk haben, es sei denn, Sie haben andere Entwicklungsanstrengungen, die Sie durchführen müssen 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 vorgenommen werden müssen.

Wenn Ihr Entwicklungs-Release-Zyklus sehr sequentiell ist, können Sie einfach wie in den anderen Antworten beschrieben vorgehen: ein Trunk und mehrere Release-Zweige. Dies funktioniert für kleine Projekte, bei denen die gesamte Entwicklung mit Sicherheit in die nächste Version fließen wird, und kann einfach eingefroren werden und als Ausgangspunkt für den Release-Zweig dienen, in dem Patches ausgeführt werden 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 Entwicklerzweig nicht "ein Zweig pro Entwickler" bedeutet (was "Wahnsinn beim Zusammenführen" auslösen würde, da jeder Entwickler die Arbeit eines anderen zusammenführen müsste, um seine Arbeit zu sehen/zu erhalten), sondern ein Entwicklerzweig 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 - das = SC Manager (der keine Ahnung hat, wie sich eine widersprüchliche Zusammenführung lösen lässt). Der Projektleiter kann die Zusammenführung überwachen, dh sicherstellen, dass sie pünktlich beginnt/endet.
  • für wen auch immer Sie sich für die Zusammenführung entscheiden, das Wichtigste ist:
    • unit-Tests und/oder Assembly-Umgebungen, in denen Sie das Ergebnis der Zusammenführung bereitstellen/testen können.
    • ein Tag definiert zu haben vor den Beginn der Zusammenführung, um in den vorherigen Zustand zurückkehren zu können, wenn sich die Zusammenführung als zu komplex erweist oder eher lange zu lösen.
107
VonC

Wir gebrauchen:

  • entwicklungszweig exklusiv

bis das Projekt fast abgeschlossen ist oder wir eine Meilensteinversion (z. B. Produktdemo, Präsentationsversion) erstellen, verzweigen wir unseren aktuellen Entwicklungszweig (regelmäßig) in:

  • zweig freigeben

Es werden keine neuen Funktionen in den Veröffentlichungszweig aufgenommen. Im Release-Zweig werden nur wichtige Fehler behoben, und der Code zur Behebung 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 weitere Zweige einführen. Jede Verzweigung hat auch einen eigenen Erstellungsprozess, dh alle paar Minuten wird ein neuer Erstellungsprozess erzeugt. Nach dem Einchecken des Codes haben wir innerhalb einer halben Stunde eine neue ausführbare Datei aller Erstellungsversionen und Verzweigungen.

Gelegentlich haben wir auch Niederlassungen für einen einzelnen Entwickler, der an einer neuen und unerprobten Technologie arbeitet oder einen Proof of Concept erstellt. Im Allgemeinen ist dies jedoch nur dann der Fall, wenn sich die Änderungen auf viele Teile der Codebasis auswirken. Dies geschieht im Durchschnitt 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 man "überspringt und direkt zur Integrationshölle geht". Ich würde dringend davon abraten. Wenn Sie eine gemeinsame Codebasis haben, sollten Sie alle zusammen daran arbeiten. Dies macht Entwickler bei ihren Check-ins vorsichtiger und mit der Erfahrung weiß jeder Codierer, welche Änderungen den Build möglicherweise beschädigen, und daher ist das Testen in solchen Fällen strenger.

Bei der frühen Check-in-Frage:

Wenn Sie nur PERFECT CODE zum Einchecken benötigen, sollte eigentlich nichts eingecheckt werden. Kein Code ist perfekt, und damit die Qualitätssicherung ihn verifizieren und testen kann, muss er sich im Entwicklungszweig befinden Eine neue ausführbare Datei kann erstellt werden.

Für uns bedeutet dies, dass ein Feature, das vom Entwickler fertiggestellt und getestet wurde, eingecheckt wird. Es 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 Bearbeitung befindlicher Code kann ebenfalls eingecheckt werden, jedoch nur, wenn dies keine offensichtlichen negativen Auswirkungen hat, wie z. B. Abstürze oder Funktionsstörungen.

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

43
steffenj

Für das, was es wert ist, ist dies, wie wir es tun.

Die meiste Entwicklung wird im Kofferraum durchgeführt, obwohl experimentelle Funktionen oder Dinge, die das System erheblich beschädigen könnten, dazu neigen, ihren eigenen Zweig zu bekommen. 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 aufzubrechen. In der Praxis kommt das nicht oft vor und ist selten ein bedeutendes Problem.

Für ein Produktions-Release verzweigen wir den Trunk, fügen keine neuen Funktionen mehr hinzu und arbeiten an der Fehlerbehebung und dem Testen des Zweigs (der regelmäßig wieder zum Trunk zusammengeführt wird), bis er für das Release bereit ist. Zu diesem Zeitpunkt führen wir eine endgültige Zusammenführung mit trunk durch, um sicherzustellen, dass alles vorhanden ist, und lassen es dann los.

Die Wartung kann dann bei Bedarf am Release-Zweig durchgeführt werden, und diese Fixes 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 straff genug), aber es funktioniert gut genug.

15
Dan

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

Es ist für mich das ultimative Verzweigungsmodell!

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

branching model

11
Philippe

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

Es muss keine "Commit Only Perfect Code" -Regel geben - alles, was der Entwickler verpasst, sollte an vier Stellen aufgegriffen werden: Codeüberprüfung, Branchentest, Regressionstest, abschließender QA-Test.

Hier ist eine detailliertere schrittweise Erklärung:

  1. Führen Sie die gesamte Entwicklung in einem Zweig durch und legen Sie dabei regelmäßig fest.
  2. Unabhängige Code-Überprüfung der Änderungen, sobald die gesamte Entwicklung abgeschlossen ist.
  3. Übergeben Sie dann den Zweig an Testing.
  4. Führen Sie nach Abschluss des Branchentests den Code in der Zweigstelle Release Candidate zusammen.
  5. Der Zweig Release Candidate wird nach jeder einzelnen Zusammenführung einer Regression unterzogen.
  6. Die abschließenden QA- und UA-Tests wurden auf RC durchgeführt, nachdem alle Entwicklungszweige zusammengeführt wurden.
  7. Nachdem QA und UAT bestanden wurden, führen Sie den Release-Zweig in den MAIN/TRUNK-Zweig zusammen.
  8. Markieren Sie abschließend den Trunk an diesem Punkt und stellen Sie diesen Tag für Live bereit.
6
Peter Boughton

dev geht in trunk (svn style) und releases (production code) bekommen ihre eigenen niederlassungen

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

4
PW.

Wir lösen dieses Problem, indem wir den Produktionscode (den Haupttrunk) vollständig vom Entwicklungscode trennen (wobei jeder Entwickler seine eigene Niederlassung hat).

Kein Code darf in den Produktionscode eingegeben werden, bevor er nicht 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.

3
Grimtron

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

Für trunk gilt nur die Regel, dass ein Commit nichts kaputt machen soll. 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 jederzeit möglich, den Stamm zu verzweigen und in Produktion zu setzen.

2
John Nilsson

Oh ja - eine andere Sache - wir behalten nicht-produktiven Code (d. H. Den, der NIEMALS veröffentlicht wird - z. B. Tool-Skripte, Test-Dienstprogramme) in cvs HEAD. Normalerweise muss es deutlich gekennzeichnet sein, damit niemand es "versehentlich" freigibt.

2
MarkR

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 steigen, wann immer dies möglich ist, während Anwendungen eine harte Deadline erreichen. Bei beiden Methoden habe ich jedoch keinen Qualitätsverlust festgestellt.

0
icco

Ich benutze Git und ich habe 2 Zweige: master und maint

  • master - Entwicklungscode
  • wartungscode

wenn ich Code für die Produktion freigebe, markiere ich ihn und füge master zu maint branch zusammen. Ich setze immer von maint Zweig ein. Patches aus dem Entwicklungszweig Ich wähle sie aus, um den Zweig zu pflegen und Patches bereitzustellen.

0
Vitalie

Wir haben eine "Release" -Zweigstelle, die enthält, was gerade in Produktion ist oder in Kürze bereitgestellt wird (die meisten QS wurden bereits bestanden).

Jedes Projekt, oder in einigen Fällen auch eine andere Einheit, hat einen eigenen Zweig, der vom Release an verzweigt ist.

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

Sobald alle Arbeitspakete in der Verzweigung einer Qualitätssicherung unterzogen wurden (Komponententest, Systemtest, Codeüberprüfung, Qualitätssicherungsü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 dem Zusammenführen ein Problem festgestellt wird. Wenn ein WP nach dem Zusammenführen "hängenbleibt", bleibt alles daran hängen, bis es behoben ist (wir können kein weiteres Release durchführen, bis das feststeckende Release freigegeben wird).


Es ist auch etwas flexibel - eine sehr triviale Änderung könnte direkt auf dem 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 Problem in der Kundenproduktion, das eine sofortige Codeänderung zur Behebung erforderlich machte), werden diese Änderungen in BRANCH_RELEASE zurückgesetzt. Das passiert so gut wie nie.

0
MarkR