SVN einrichten, um am besten Dev -> QA -> Prod

Question

Es tut mir leid, wenn dies bereits gefragt worden ist, aber ich habe nicht in der Lage gewesen, eine Antwort, die für diese Situation zu finden:

Für unsere web Anwendung, wir haben 3 Systeme: Entwickler, QA und Produktion. Im Moment wird der Code von einer dritten Partei verwaltet, aber bald wird es in unseren Händen sein. Wir werden separate Build-Umgebungen für jede Phase haben. Außerdem verwenden wir RAD für die Code-Entwicklung, so dass es eigentlich einen primären Schritt, Test/Sandbox, geben wird.

Im Idealfall würden wir gerne Repositories für jede Phase isolieren, so dass wir aus DEV auschecken, einige Änderungen vornehmen, sie lokal testen und sie wieder in DEV überprüfen. Wenn bei Dev alles in Ordnung ist, werden wir in QA einchecken und so weiter.

Sollten wir separate Repositories für jeden haben, oder würde dies unter "Branching" fallen, wo wir einen separaten Zweig für Dev, QA und Prod haben würden. Könnten Sie auch die beste Möglichkeit bieten, die ideale Route zu implementieren?

Lassen Sie mich wissen, wenn es noch andere Fragen gibt.

Dank Chris

Answer 1

Verwendung Branching und Merging

Wir haben die folgenden Möglichkeiten verwechselt werden sollte:

Wenn wir veröffentlichen wir ein erstellen Aktueller Release-Zweig. Wir machen hier zwischen Releases Fehlerbehebungen und führen sie dann wieder in unseren Stamm zurück.

Wir entwickeln auf Stamm und wenn wir bereit sind zu veröffentlichen, machen wir einen QA-Zweig. Wir testen und fixieren es und schieben es dann raus und es wird unser aktueller Release-Zweig.

Answer 2

Sie sollten ein einziges Repository haben, die ausgecheckt oder während des Verteilungsprozesses exportiert werden kann.

Wir haben auch eine ähnliche Einstellung. Entwickler checken eine lokale Arbeitskopie aus und entwickeln sie in ihrer Entwicklungsumgebung. Wenn wir bereit sind, die Bühne zu betreten, oder QA, wie Sie es nennen, machen wir einen SVN-Export in diese Umgebung (oft von Kopf, aber wir behalten immer den Überblick über die spezifische Revision).

Während des QA-Prozesses entwickeln wir weiter im Entwicklungsprozess und implementieren zur Qualitätssicherung.

Schließlich, wenn wir bereit für die Produktion sind, exportieren wir die richtige Revision aus dem Repository in die Produktionsumgebung.

Funktioniert gut!

[Edit: soweit 'diese Verzweigung' - was Sie beschreiben, ist wahrscheinlich mehr wie Revisionen zu verfolgen. Die Verzweigung ist jedoch eine sehr wichtige Technik, um verschiedene Entwicklungslinien zu verwalten. dies nicht mit einem anderen Zweig für jede Stufe (dev, Bühne, leben), unbedingt]

Answer 3

Dies funktioniert gut, wenn Sie an einem einzigen Entwicklungsstrom mit leicht bestätigten Aufgaben arbeiten. Aber es wird mit mehreren Entwicklungspfaden und der Möglichkeit, die Aufgaben herauszuziehen oder zu verzögern, eine größere Herausforderung darstellen. Sie würden dann eine Art Zeitabhängigkeit in Ihrer Anwendung benötigen. Sie können auch Feature-Zweige verwenden, die nach dem Erstellen des Features wieder in den Stamm eingefügt werden.

Answer 4

Check out Scott Cowan Blog-Post:

http://sleepoverrated.com/archive/2007/12/buildknowledgepromotingyourbuild/

Er hat einen großen Artikel über Ihren Code zu unterschiedlichen Umgebungen zu fördern. Es beinhaltet das Schreiben einiger Build-Skripte, wird aber den Prozess verbessern. Es wird es auch erlauben, etwas zu automatisieren.

Answer 5

Wir haben ein ähnliches Schema. In SVN haben wir 3 Filialen, trunk, PREPROD und PROD. Immer wenn neue Funktionen zum Testen bereit sind, werden sie in den Zweig PREPROD zusammengeführt (nur mit bestimmten Revisionsnummern und nur für bestimmte Dateien). Wenn QA bestanden wird, wird sie festgeschrieben und in den Zweig PROD zusammengeführt. Wenn Änderungen im Zweig PROD festgeschrieben werden, werden sie automatisch auf allen Produktionsservern bereitgestellt. Außer beim Testen neuer Funktionen sind PREPROD und PROD gleich.

Answer 6

Wir haben einen Entwicklungszweig für jedes Bugfix, Feature oder Task, und involvierte Projekte neigen dazu, mehrere Unterzweige zu haben.

Anfangs ist es wierd, einen neuen Zweig für nur eine Zeile Code-Fix zu erstellen, aber es erlaubt, den Stamm in den Zweig zu verschmelzen, dann Regressionstests und schließlich wieder in Stamm zu verschmelzen.

Im Idealfall bedeutet dies, dass alles, was in den Trunk integriert wird, den Build nicht unterbricht und dass Sie keine Angst davor haben, Ihren Code für einen zerbrechlichen Build zu verwenden.

Ich verwende oft mehrere Zweige für das eine Problem, testet verschiedene Lösungen aus, während ich immer noch die Vorteile von SCM nutze.

Wir markieren auch bestimmte Versionen oder Releases, die eine schnelle Bereitstellung basierend auf bekanntem guten Code ermöglichen.

Viele unserer webbasierten Systeme verwenden svn: externals, die auf bestimmte Versionen von Abhängigkeiten wie Bibliotheken und Herstellercodes verweisen. Eine Bereitstellung wird von den externen Elementen übernommen und nicht von einem direkten Checkout oder Export.