Downgrade dank Versionsverwaltung möglich?
Hallo zusammen
Wir haben folgende Situation. Aktuell führen wir eine neue Software ein. Der Hersteller schickt uns hier Key-Account-Manager die technisch nicht sehr pfiffig sind. Soweit so gut. Nun hatten wir gerade die Diskussion, ob wir auf der Testinstanz im Falle eines Falle ein SW-Downgrade machen können. Der Hersteller meinte; "nicht in allen Fällen".
aber ist nicht gerade auch das die Idee einer Versionsverwaltung?
Use-Case
Wir haben zwei Systeme:
- Produktion und
- Testumgebung
Wir habe eine Versionsverwaltung (Git) von der aus wir die SW entsprechend deployen. Sowohl auf Testumgebung als auch auf Prod.
So, nun hat man es offenbar verpasst, die Regeln für die Testumgebung festzusetzen. Der Hersteller (welcher aktuell bei uns im Haus ist) verlangt von uns immer wieder, dass wir RC (Release Candidates) auf die Testumgebung spielen. Was auch nicht dramatisch ist. Problem ist nur, dass wir offenbar die Softwareparität ausser Acht lassen. Denn was ich gerne hätte, wäre eine Produktion und eine Testumgebung die zumindest potenziell den selben Softwarestand fahren können. Dann kann man auf der Testumgebung spielen so viel man will, man kann jederzeit die Produktion 1:1 abbilden. Zumindest auf Softwareebene.
Nun gehe ich davon aus, dass man mit der Versionsverwaltung genau das kann. Also eine alte Version mit dem Master Mergen und dann deployen. Der Hersteller (technisch vielleicht nicht affin, da Verkäufer im Haus) meint, dass das nicht zwingend geht. Da beim RC oder bei welcher Version auch immer Tabellen bzw. die DB neu organisiert wird.
aber ich gehe eben genau davon aus, dass eine alte SW-Version die Tabellen bzw. DB Schemen dann wieder so um- und überschreibt wie sie das zum Versionsstand XYZ aus der Vergangenheit gemacht hat.
bin ich hier völlig auf dem Holzweg? Eine Versionsverwaltung bringt mir in dem Fall doch herzlich wenig, wenn ich kein Fallback bzw. Downgrade machen kann. richtig?
Grüsse euch, danke für eure Gedanken im Voraus.
1 Antwort
Eine gute Frage.
Erstmal stimme ich dir was dir Testumgebung angeht vollkommen zu: diese muss möglichst der Produktionsumgebung entsprechen um ein sinnvolles Testen zu ermöglichen. Natürlich ohne Verbindungen nach außen, diese müssen simuliert werden.
Was die Versionserinnerung angeht, kannst du natürlich beliebig hin und her springen, aber da eine Datenbank dabei ist, muss hierbei auch immer das Schema wieder angepasst werden. Für das Upgrade auf ein geändertes Schema sollte es entsprechende Update SQL Skripte geben, die das Schema auf die neue Version anpassen.
Beim downgrade habt ihr zwei Optionen: entweder ihr setzt die Datenbank mit dem vorherigen Schema neu auf (auf Testumgebung theoretisch möglich) oder lasst euch entsprechende downgrade SQL Skripte schreiben die nötigen Änderungen vornehmen (kostet garantiert extra).
Dabei ist zu beachten, dass die Daten die in die DB kommen natürlich dem jeweiligen Schema entsprechen müssen.
Vielen Dank für deine Antwort. Das heisst somit, dass wir ein spezielles DB-Downgrade-Skript (nennen wir das mal so) brauche? Ich ging davon aus, dass die VersionXYalt die DB so oder so schreibt, wie sie das in der Vergangenheit ja auch gemacht hat. Also am Ende des Tages würde die VersionXYalt die VersionXYaktuell sowohl Software-Versions-technisch als auch die DB komplett überschrieben. Die Daten in der Testumgebung-DB-Aktuell würden natürlich mit Testumgebung-DB-Alt komplett überschrieben.
also konkret könnte die VersionXYalt nicht aus dem Stand heraus mit der Testumgebung-DB-Aktuell dealen. Da brächte es dann dein Downgrade-Skript m.E.
aber wenn die VersionXYalt die Testumgebung-DB-Aktuell mit der Testumgebung-DB-alt überschreibt gäbe es doch kein Problem. Oder ist das nicht möglich und dafür bräuchte es das Skript?
danke dir für den Input. Super Feedback von vorhin...