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.
