Wir haben einen "Release"-Zweig, der das enthält, was derzeit in Produktion ist oder in Kürze bereitgestellt wird (die meisten QAs wurden bereits bestanden).
Jedes Projekt, oder in manchen Fällen auch eine andere Einheit, hat seinen eigenen Zweig, der von Release abgezweigt wird.
Änderungen werden von den Entwicklern des Projekts in den eigenen Zweig des Projekts übertragen. In regelmäßigen Abständen wird die Freigabe in einen Entwicklungszweig zurückgeführt.
Sobald alle Arbeitspakete des Zweigs qualitätsgesichert sind (Unit-Test, Systemtest, Code-Review, QA-Review usw.), wird der Zweig mit dem Release-Zweig zusammengeführt. Die neue(n) Version(en) wird/werden aus dem Freigabezweig erstellt, und die endgültige Validierung erfolgt für diese Version.
Der Prozess ist grundsätzlich in Ordnung, bis ein Problem entdeckt wird, nachdem eine Zusammenführung erfolgt ist. Wenn ein WP nach der Zusammenführung "stecken bleibt", hält es alle folgenden auf, bis es behoben ist (wir können keine weitere Veröffentlichung vornehmen, bis das stecken gebliebene WP freigegeben ist).
Es ist auch einigermaßen flexibel - eine sehr triviale Änderung könnte direkt auf dem Versionszweig stattfinden, wenn es in einem sehr kurzen Zeitrahmen (etwa 1-2 Tage oder so) veröffentlicht wird.
Wenn eine Änderung aus irgendeinem Grund direkt in die Produktion übernommen wird (ein kritisches Problem mit Auswirkungen auf die Produktion, das eine sofortige Codeänderung zur Behebung erfordert), werden diese Änderungen wieder in BRANCH_RELEASE aufgenommen. Das passiert so gut wie nie.
0 Stimmen
Ich habe eine ähnliche Frage (oder besser gesagt, eine Frage in der gleichen Richtung) schon einmal beantwortet, also sollten Sie sich diese Frage vielleicht ansehen: Was sind gute Strategien, um die Hotfix-Fähigkeit von bereitgestellten Anwendungen zu ermöglichen?
0 Stimmen
@revo: Moment... meine Antwort von 2008 ist veraltet? :) Ich nehme an, das ist sie in der Tat. Es ist schon mehr als 10 Jahre her: Ich habe meine Antwort bearbeitet.