Was ist Ihr bevorzugter Web-App-Bereitstellungsworkflow mit SVN?

Question

Wir verwenden derzeit ein etwas kompliziertes Bereitstellungssetup, das einen Remote-SVN-Server, drei SVN-Zweige für DEV, STAGE und PROD umfasst und Code zwischen ihnen durch Patches usw. fördert.Ich frage mich, was Sie für die Bereitstellung in einer Situation mit einem kleinen Entwicklerteam verwenden.

Answer 1

Stamm für die Entwicklung und ein Zweig (Produktion) für die Produktionssachen.

Auf meinem lokalen Computer habe ich einen VirtualHost, der auf den Trunk-Zweig verweist, um meine Änderungen zu testen.

Jeder Commit für Trunk löst einen Commit-Hook aus, der einen SVN-Export und eine Synchronisierung mit der Entwickler-URL des Online-Servers durchführt. Wenn die Site also stackoverflow.com lautet, aktualisiert dieser Hook automatisch dev.stackoverflow.com

Dann verwende ich svnmerge, um in meinen lokalen Checkouts ausgewählte Patches vom Trunk in die Produktion zusammenzuführen.Ich habe wieder einen VirtualHost auf meinem lokalen Computer, der auf den Produktionszweig verweist.

Wenn ich die zusammengeführten Änderungen in den Produktionszweig übertrage, aktualisiert erneut ein SVN-Export-Hook den Produktions-(Live-)Export und die Site ist live!

Answer 2

Als ich in einem kleinen Entwicklerteam arbeitete (klein bedeutete ich, ein anderer Programmierer und der Chef), herrschte ein ziemlich chaotisches Durcheinander.Wir haben jedoch festgestellt, dass die Zuweisung eines Prozesses vom Typ „Gatekeeper“ für uns funktioniert.

Der Gatekeeper war die Person, die am meisten an der App gearbeitet hatte (in diesem Fall hatte ich zwei Projekte, die ich von Grund auf entwickelt hatte, er hatte ungefähr vier).

Wann immer er an meinen Projekten arbeiten musste, teilte er mir grundsätzlich mit, dass er mit der Arbeit beschäftigt war. Ich stellte sicher, dass das Repository auf dem neuesten Stand und baubar war, und dann zog er es herunter, nahm seine Änderungen vor und führte dann einen Commit durch .Er teilte mir mit, dass es fertig sei, ich würde es abreißen, bauen und einsetzen.Wenn es DB-Änderungen gab, hatten wir einen DB-Change-Ordner mit allen Skripten, die die DB korrigieren würden.

Offensichtlich gibt es viele Lücken, aber der Prozess hat für uns funktioniert und uns davon abgehalten, uns gegenseitig weiterzuentwickeln.

Answer 3

Ich hatte keine Probleme mit der allgemeinen Organisation von Tags/Zweigen/Trunk.

Die allgemeine Weiterentwicklung findet im Stamm statt.

Die Wartung eines Releases in der Produktion erfolgt im entsprechenden Release-Zweig.

Änderungen am Release-Zweig, die noch für Trunk relevant sind, werden zusammengeführt.

Wenn eine neue Version zur Bereitstellung bereit ist, wird sie vom Stamm aus markiert und anschließend wird aus diesem Tag ein Zweig erstellt.Der neue Release-Zweig wird parallel zum aktuellen Release auf den Server ausgecheckt.Wenn es Zeit ist zu wechseln, werden die Pfade jongliert („mv appdir appdir.old && mv appdir.new appdir“).

Entwickler, die die Produktionsversion unterstützen, wechseln dann svn ihre Arbeitskopie auf den neuen Zweig oder führen einen erneuten Checkout von diesem aus durch.

Answer 4

Drei Zweige klingen einfach nach zusätzlicher Arbeit.

Umgebungsunterschiede können dadurch bewältigt werden, dass unterschiedliche Versionen der relevanten Dateien im Stamm vorhanden sind.d.h.Datenbank.yml und Datenbank.yml.prod.Der Bereitstellungsprozess sollte umweltbewusst sein und einfach die Dateien pro Umgebung über die Standarddateien kopieren.

Answer 5

Ein einfacher Trunk-Zweig enthält den aktuellsten Code und schneidet dann einen Zweig ab, wenn wir live gehen.Das scheint ziemlich effektiv zu funktionieren.Sie können problemlos zum vorherigen Zweig wechseln, wenn der aktuelle Zweig, den Sie für das Live-System geschnitten haben, ausfällt.Außerdem ist es einfach, Fehler in dem Zweig zu beheben, der gerade aktiv ist, und da der Zweig effektiv stirbt, wenn Sie einen neuen Zweig schneiden, müssen Sie immer nur an einem echten Zweig arbeiten (und dann Korrekturen von dort in den Zweig zusammenführen). Live-Zweig).

Answer 6

Wir nutzen Branches nicht für die Bereitstellung webbezogener Inhalte;nur zum Testen experimenteller Dinge, die lange dauern werden (lesen Sie:mehr als einen Tag), um wieder in den Stamm zu verschmelzen.Der Stamm stellt im Stil der „kontinuierlichen Integration“ einen (hoffentlich) funktionierenden, aktuellen Zustand dar.

Daher werden die meisten Änderungen direkt in den Trunk übernommen.Ein CruiseControl.NET-Server wird automatisch auf einem Computer aktualisiert, auf dem auch IIS ausgeführt wird und über aktuelle Kopien aller Ressourcen der zusätzlichen Site verfügt, sodass die Site intern vollständig und sauber getestet werden kann.Nach dem Test werden die Dateien auf den öffentlichen Server hochgeladen.

Ich würde nicht sagen, dass es der perfekte Ansatz ist, aber er ist einfach (und daher für unser relativ kleines Personal geeignet) und relativ sicher und funktioniert einwandfrei.

Answer 7

Trunk enthält die aktuelle „primäre“ Entwicklungscodebasis.

Ein Entwickler erstellt häufig einen einzelnen Zweig für jedes mittel- bis langfristige Projekt, der die Stammcodebasis belasten und den anderen Entwicklern im Weg stehen könnte.Wenn er fertig ist, verschmilzt er wieder mit dem Kofferraum.

Wir erstellen jedes Mal ein Tagged-Release, wenn wir Code in die Produktion übertragen.Der Ordner in /tags ist einfach die Versionsnummer.

Für die Bereitstellung in der Produktion führen wir einen SVN-Export ins Staging durch.Wenn das zufriedenstellend ist, verwenden wir einen einfachen Rsync, um den Rollout auf den Produktionsclustern durchzuführen.

Answer 8

Ich kann das Buch nur wärmstens empfehlen (derzeit in Rohfassungen) Kontinuierliche Lieferung, das einen vollständigen Prozess zur Verwaltung der Softwarebereitstellung beschreibt, der (unter anderem) auf Prinzipien der kontinuierlichen Integration basiert.

Ich mag den Branch-and-Merge-Ansatz überhaupt nicht, da er sehr chaotisch werden kann und ziemlich verschwenderisch ist, da man am Ende Zeit mit Aktivitäten verschwendet, die eigentlich keinen neuen Wert liefern.Sie haben Ihren Code bereits einmal entwickelt, getestet und korrigiert. Warum sollten Sie eine Situation schaffen (Kopieren des Codes in einen anderen Zweig), in der Sie diese Arbeit wiederholen müssen?

Wie auch immer, die Möglichkeit, Verzweigungen und Zusammenführungen zu vermeiden, besteht darin, Ihre bereitstellbaren Artefakte aus dem Stamm zu erstellen und die erstellten Artefakte (und nicht die Quelle) hochzustufen, wenn sie Tests, Staging usw. bestehen.Auf diese Weise sind Sie zu 100 % sicher, dass das, was Sie in Produktion bringen, dasselbe ist, was Sie getestet haben.

Wenn Sie verschiedene Funktionen haben, die möglicherweise nach unterschiedlichen Zeitplänen veröffentlicht werden müssen, kann eine Änderung Ihres Implementierungsansatzes (Funktionalität konfigurierbar oder besser noch modular gestalten) dabei helfen, einen einzigen Entwicklungsstamm beizubehalten.

Answer 9

Wir verwenden Release-Branching – das scheint für uns effizienter zu sein als das Feature-Branching, das wir bisher durchgeführt haben.

Erstellen Sie keine unterschiedlichen Zweige für die verschiedenen Umgebungen.

Answer 10

Ich persönlich arbeite lokal (Entwicklung), füge Funktionen hinzu/repariere sie und wenn ich denke, dass sie fertig ist, verpflichte ich mich zum Trunk (Produktion).Auf dem Produktionsserver führe ich einfach ein SVN-Update durch.

Answer 11

Ich arbeite mit einer ähnlichen Situation wie Sie derzeit.Ich wurde damit beauftragt, eine „bessere“ Lösung zu finden, und sie lief in etwa wie folgt ab.

Der Live-Zweig stellt die Server in ihrem aktuellen Zustand dar.

Jegliche Entwicklungsarbeit sollte in einem Zweig erfolgen, der aus dem Live-Betrieb übernommen wird.Dies kann ein halbstündiger Job für eine Person oder ein einjähriges Projekt mit mehreren Teams sein.In diese Entwicklungszweige können beliebig oft Wohnveränderungen eingebunden werden.

Bevor eine Arbeit live geht, werden die Live-Änderungen noch einmal zusammengeführt und als potenzielle Veröffentlichung gekennzeichnet.Diese Version wird in der Staging-Umgebung getestet und wenn sie den Test besteht, wird die neue Version aus dem Tag übernommen.

Es ist möglich, mehrere Arbeiten in einem Release zusammenzuführen, wenn das besser funktioniert.

Dies bedeutet, dass es ziemlich einfach ist, Entwicklungszweige live auf dem neuesten Stand zu halten, und wenn ein Teil der Entwicklungsarbeit verloren geht, ist nur minimaler Aufräumaufwand erforderlich.

Um von der Arbeit an einem Projekt zu einem anderen zu wechseln, kann ein Entwickler einfach seine lokale Arbeitsumgebung per SVN auf einen anderen Zweig umstellen.

Eines der Probleme, die wir mit dem von Ihnen beschriebenen System hatten, besteht darin, dass DEV mit PROD ziemlich schnell veraltet sein kann, sodass Sie nicht gegen das Live-System entwickeln und es nicht einfach ist, wechselseitige Abhängigkeiten bis zur Phase zu erkennen.Die obige Lösung löst diese Probleme und bleibt dennoch relativ leichtgewichtig.