Hallo alle Miteinander (da es sicherlich auch andere interessiert),
Hier mal ei paar Hintergrund Informationen, warum das Update aktuell so ist wie es ist und was sich in nächster Zeit daran tun wird.
Wir bei zollsoft haben das dringend "auf dem Schirm" da Verbesserungen herbeizuführen.
Generell Backup bei einem Update, warum?
Im Prinzip bin ich hier sehr konservativ, lieber ein Backup mehr als eins zu wenig - wenn bei einem Update etwas schiefgeht,
kann man um Zweifel alles so wieder herstellen, wie es vor dem Update war. In der Software sind einige Kniffe drin, die eine
"one click rollback" Funktion für die Techniker ermöglichen - damit minimale Ausfälle gewährleistet werden können,
wenn "mal so richtig was schiefgegangen ist"
Insbesondere beim Q Update ist ein "BaseBackup" "Gold Wert", daher diese Option unter keinen Umständen deaktivieren.
Das Backup läuft aber auch nur bei einer Datenbank Migration, für alle anderen Fälle ist das "normale, aka primäre Backup" da.
Die Option "Backup-Kopien überspringen" ist in einer der nächsten Versionen immer "an" - d.h. es wird nur noch das primäre Backup und ggf. ein BaseBackup (DB Migration) erstellt. Da es wirklich als "nervig" eingestuft wurde auch immer die "externen" Backups als Fehlerquelle mit bei einem Update zu haben.
Was wird sich ändern beim Update?
Zunächst, die Schritte sind bewusst langsam, weil ein "Aussperren" vermieden werden soll.
Was immer gewährleistet sein muss, dass ein "falsches Update" auch wieder "Updates einspielen" kann.
Daher sind wir hier bei den ServerTools in dem Bereich "extrem vorsichtig".
Was bereits passiert ist, ...
- Pre Downloads (damit kann zumindest bei einem Fehlschlag auf das bereits heruntergeladene zugegriffen werden), Bei Px mit einer etwas langsameren Internetverbindung sicherlich vom Vorteil - es handelt sich hier um ein eher "verstecktes" Feature von dem man im Zweifel gar nichts mitbekommt.
- Überarbeitung der "Fehlermeldungen" bei einem Update. Nicht jeder Fehler ist ein Update-Fehler, nur wurde das bisher immer "suggeriert", da die Darstellung (zugegebenermaßen) sehr suboptimal ist. Dieses Feature befindet sich gerade im Test, da es massiv in den Ablauf eines Updates eingreift und oben erwähntes "Aussperren" vermieden werden soll.
Was wird kommen, ...
- In der Überlegung sind z.B. "intelligenteres Auswürfeln" der Backups - tatsächlich, wenn ein BaseBackup existiert und der tomedoServer seit der Erstellung nicht gestartet wurde - kann man dieses als "gültig" ansehen und muss es nicht noch einmal machen
- bessere Prozesskontrolle, nicht jeder Service/Process muss bei einem Update heruntergefahren werden (Stichwort: HAEVG)
- Trennung des tomedoServer von dem "Gesamtprodukt". Hier geht es darum, dass wir aktuell "einfach zu viel Austauschen" und diesen Prozess etwas entschlacken wollen. Insbesondere die Px mit dem "nach einem Update startet nichts", werden davon profitieren, da nach aktueller Lesart ein Update des tomedoServer kein kompletter Austausch der "Gesamtsoftware" erfordert. Das befindet sich gerade in der Evaluation, da die Trennung auch die Update-Kette betrifft.
"Vision / Überlegungen", ...
- mehr oder weniger Königsdisziplin beim Update sind "Differenzielle" Updates, die würden dann nur noch das austauschen, was sich auch wirklich geändert hat. in der Entwicklung passiert so was schon - da bei einem Entwickler, sich nicht immer die gesamte Software ändert, sondern nur die Teile die er wirklich anfasst. es wäre grausam, auf den Testmaschinen, dann immer volle Updates einzuspielen. Ob das kommen wird, kann ich aktuell hier nicht beantworten - da diese Art der Updates auch ein anderes Deployment verlangen würde, was noch weitere Teile der Update-Kette betreffen wird.
Ich hoffe, das hilft etwas zu verstehen, warum die Updates aktuell so sind wie sie sind. Ich betone noch einmal, dass wir der Sache wirklich bewusst sind. Die Fortschritte aber eher "TippelTappel" passieren.
Mit freundlichen Grüßen
Andreas Reinhardt