Wir verwenden derzeit ein etwas kompliziertes Deployment-Setup, das einen Remote-SVN-Server, drei SVN-Zweige für DEV, STAGE und PROD beinhaltet, um Code zwischen ihnen durch Patches zu promoten usw. Ich frage mich, was Sie für die Bereitstellung in einem kleinen Entwickler verwenden Team Situation?Was ist der bevorzugte Workflow für die Bereitstellung von Web-Apps mit SVN?
Stamm für die Entwicklung, und eine Niederlassung (Produktion) für die Produktion stuff.
Auf meinem lokalen Computer habe ich einen VirtualHost, der auf den Stammzweig zeigt, um meine Änderungen zu testen.
Beliebig Stamm begehen löst einen Haken begehen, die einen SVN-Export und Synchronisierung in den Online-Server dev URL tut - also, wenn die Seite ist stackoverflow.com dann dieser Haken automatisch aktualisiert dev.stackoverflow.com
ich dann Verwenden Sie svnmerge, um ausgewählte Patches von Trunk zu Produktion in meinen lokalen Checkouts zusammenzuführen.Ich habe wieder einen VirtualHost auf meinem lokalen Rechner, der auf den Produktionszweig zeigt.
Wenn ich die zusammengeführten Änderungen in den Produktionszweig festlege, aktualisiert ein SVN-Export-Hook erneut den Produktionsexport (Live-Export) und die Site ist live!
Ein einfacher Stammzweig enthält den aktuellsten Code, dann schneiden wir einen Zweig, wenn wir live gehen. Dies scheint ziemlich effektiv zu funktionieren. Sie können jederzeit zum vorherigen Zweig wechseln, wenn der aktuelle Zweig, den Sie für das Live-System geschnitten haben, fehlschlägt. Außerdem ist es einfach, Fehler in der Zweigstelle zu beheben, die gerade aktiv ist, und da die Verzweigung effektiv endet, wenn Sie eine neue ausschneiden, gibt es immer nur einen echten Zweig, an dem Sie arbeiten müssen lebende Niederlassung).
Als ich in einem kleinen Entwicklerteam arbeitete (klein, was mich, einen anderen Programmierer und den Chef bedeutet), war es ziemlich chaotisch. Wir haben jedoch festgestellt, dass die Zuweisung eines "Gatekeeper" -Typs für uns funktioniert hat.
Der Gatekeeper war die Person, die am meisten an der App gearbeitet hatte (in diesem Fall hatte ich 2 Projekte, die ich von Grund auf entwickelte, er hatte 4).
Grundsätzlich, wann immer er an meinen Projekten arbeiten musste, teilte er mir mit, dass er Arbeit verrichten würde, ich würde sicherstellen, dass das Repository aktuell und baubar wäre, dann würde er runterziehen, seins machen Änderungen, dann commit. Er würde mir mitteilen, dass es gemacht wurde, ich würde herunterziehen, bauen und einsetzen. Wenn DB-Änderungen vorhanden waren, hatten wir einen DB Change-Ordner mit allen Skripten, die die DB korrigieren würden.
Es hat offensichtlich viele Löcher, aber der Prozess hat für uns funktioniert und uns davon abgehalten, uns gegenseitig zu überholen.
Drei Zweige klingt nur wie zusätzliche Arbeit.
Umgebungsdifferenzen können durch verschiedene Versionen der relevanten Dateien im Trunk behandelt werden. d.h. database.yml & database.yml.prod. Der Bereitstellungsprozess sollte umweltbewusst sein und einfach die Dateien pro Umgebung über die Standarddateien kopieren.
Wir verwenden keine Zweige zum Staging von Web-bezogenen Inhalten; nur zum Testen von experimentellen Dingen, die eine lange Zeit brauchen (sprich: mehr als einen Tag), um wieder in den Stamm zu kommen. Der Stamm, im Stil der "kontinuierlichen Integration", repräsentiert einen (hoffentlich) funktionierenden, aktuellen Zustand.
So werden die meisten Änderungen direkt an den Stamm gebunden. Ein CruiseControl.NET-Server wird automatisch auf einem Rechner aktualisiert, auf dem auch IIS ausgeführt wird, und verfügt über aktuelle Kopien aller verfügbaren Ressourcen der zusätzlichen Site, sodass die Site vollständig und sauber intern getestet werden kann. Nach dem Testen werden die Dateien auf den öffentlichen Server hochgeladen.
Ich würde nicht sagen, es ist der perfekte Ansatz, aber es ist einfach (und damit für unsere relativ kleinen Mitarbeiter geeignet) und relativ sicher, und funktioniert gut.
Wir verwenden Release-Branching - das scheint für uns effizienter zu sein als die Feature Branching, die wir machten.
Erstellen Sie keine verschiedenen Zweige für die verschiedenen Umgebungen.
Trunk enthält die aktuelle "primäre" Codebasis für die Entwicklung.
Ein Entwickler wird oft einen einzelnen Zweig für jedes mittel- bis langfristige Projekt erstellen, das die Stammcodebasis schleusen und den anderen Entwicklern in die Quere kommen könnte. Wenn er fertig ist, wird er in den Kofferraum zurückkehren.
Wir erstellen eine getaggte Version jedes Mal, wenn wir den Code in die Produktion schieben. Der Ordner in/tags ist einfach die Versionsnummer.
Zur Bereitstellung in der Produktion führen wir einen SVN-Export in Staging durch. Wenn das zufriedenstellend ist, verwenden wir ein einfaches rsync, um zu den Produktionsclustern zu gelangen.
Ich persönlich arbeite lokal (Entwicklung), Hinzufügen/Fixieren von Funktionen und wenn ich denke, dass es fertig ist, begib ich mich zu Stamm (Produktion). Auf dem Produktionsserver mache ich einfach ein svn update.
Ich arbeite mit einer ähnlichen Situation wie Sie derzeit haben. Ich hatte den Auftrag, eine "bessere" Lösung zu finden, und sie entsprach etwa dem Folgenden.
Der Live-Zweig repräsentiert die Server in ihrem aktuellen Status.
Alle Entwicklungsarbeiten sollten in einer Zweigstelle durchgeführt werden, die aus dem Live-Bereich stammt. Dies könnte ein Ein-Personen-Halbstundenjob oder ein einjähriges Multi-Team-Projekt sein. So oft es erwünscht ist, können Änderungen am Leben in diese Entwicklungszweige eingebunden werden.
Bevor ein Stück Arbeit live geht, werden Änderungen vom Live wieder zusammengeführt und es wird als eine mögliche Veröffentlichung markiert. Diese Version wurde in der Staging-Umgebung getestet. Wenn die Tests bestanden werden, wird das neue Live vom 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 mit Live auf dem neuesten Stand zu halten, und wenn ein Stück Arbeit in der Entwicklung fallen gelassen wird, gibt es minimale Aufräumarbeiten.
Um von einem Projekt zum anderen zu wechseln, kann ein Entwickler einfach seine lokale Arbeitsumgebung in einen anderen Zweig wechseln.
Eines der Probleme, die wir mit dem System hatten, wie Sie beschreiben, ist, dass DEV relativ schnell veraltet sein kann, so dass Sie sich nicht gegen das Leben entwickeln und es nicht einfach ist, Abhängigkeiten bis zur Stufe zu erkennen. Die obige Lösung löst diese Probleme, während sie immer noch ziemlich leicht bleibt.
Ich hatte keine Probleme mit der allgemeinen Tags/Zweige/Trunk-Organisation.
Allgemeine laufende Entwicklung passiert im Kofferraum.
Die Wartung eines Releases in der Produktion erfolgt im entsprechenden Release-Zweig.
Änderungen zum Freigabezweig, die noch für den Stamm relevant sind, werden zusammengeführt.
Wenn eine neue Version zur Bereitstellung bereit ist, wird sie aus dem Stamm markiert, und dann wird eine Verzweigung aus diesem Tag erstellt. Der neue Release-Zweig wird parallel zum aktuellen Release auf dem Server ausgecheckt. Wenn es Zeit ist zu wechseln, werden die Pfade jongliert ("mv appdir appdir.old & & mv appdir.new appdir").
Entwickler, die die Produktionsfreigabe unterstützen, dann svn schalten ihre Arbeitskopie in den neuen Zweig oder führen einen neuen Checkout durch.
Ich empfehle das Buch (derzeit in groben Schnitten) Continuous Delivery, die einen vollständigen Prozess für die Verwaltung der Software-Lieferung beschreibt, basierend auf den Prinzipien der kontinuierlichen Integration (unter anderem).
Ich mag den Zweig- und Zusammenführungs-Ansatz nicht, da er sehr unordentlich werden kann, und ist ziemlich verschwenderisch, da Sie am Ende Zeit mit Aktivitäten verbringen, die keinen neuen Wert liefern. Sie haben Ihren Code bereits einmal entwickelt, getestet und repariert. Warum sollten Sie eine Situation erstellen (den Code in einen anderen Zweig kopieren), für die Sie diese Arbeit wiederholen müssen?
Wie auch immer, die Möglichkeit, Verzweigungen und Zusammenführungen zu vermeiden, besteht darin, die implementierbaren Artefakte aus dem Stamm zu erstellen und die gebauten Artefakte (anstatt der Quelle) zu fördern, während Test, Staging usw. bestanden werden Was du in Produktion bringst, ist dasselbe, was du getestet hast.
Wenn Sie verschiedene Funktionen haben, die möglicherweise zu unterschiedlichen Zeitplänen freigegeben werden müssen, können Sie Ihren Entwicklungsansatz ändern, indem Sie Ihren Ansatz ändern (Funktionalität konfigurierbar oder besser noch modular).
Das Buch ist jetzt erschienen, und es scheint gut von dem, was ich gelesen habe. –
Ich mag das, aber wie halten Sie Ihre Datenbank-Updates im Einklang mit dieser Methode? – cgreeno
Der Website-Code behandelt Aktualisierungen der Datenbank von einer Administrator-URL aus, und es gibt eine Versionsnummer der Datenbank, um zu wissen, wann ein Upgrade durchgeführt werden muss. –