Staging-Prozess für ein sicheres Deployment
Bei der Einführung eines neuen Systems auf der grünen Wiese ist noch alles in bester Ordnung. Die Versionen der einzelnen Komponenten sind perfekt aufeinander abgestimmt, alle Testszenarien sind vollumfänglich durchgespielt und abgenommen. Dem „going live“ steht nichts mehr im Weg und das bisher zur Entwicklung und zum Test verwendete System wird nun zum Produktivsystem ernannt. Aber was passiert im Laufe des Produktzyklus mit Erweiterungen und Updates? Keiner möchte zukünftig direkt mit dem Produktivsystem arbeiten und quasi am offenen Herzen operieren. Die Einführung eines Staging-Prozesses ist hier die ideale Lösung.
Im Laufe des Entwicklungsprozesses eines neuen Produkts oder Systems gibt es unterschiedliche Schritte bis zur Fertigstellung. Beginnend mit der Entwicklung von Komponenten über ausführliche Tests bis zur Freigabe und Veröffentlichung gibt es einen kontinuierlichen Kreislauf der einzelnen Prozessschritte während des gesamten Produktlebenszyklus. Zu jedem Schritt gehört idealerweise eine eigene Serverumgebung, um gegenseitige ungewollte Einflüsse zu verhindern.
Entwickler arbeiten auf einem eigenen Developer-System (D) mit festgelegten Randbedingungen, was beispielsweise die Version des Betriebssystems, den verwendeten Compiler und die eingebundenen Bibliotheken und Frameworks anbetrifft, und erzeugen daraus jeweils freigegebene Zwischenstände und schließlich auch das finale Release der Software. Die Qualitätssicherung führt auf einem davon völlig unabhängigen System (Q), aber mit gleichen festgelegten Randbedingungen wie auf dem D-System, die Tests durch und erteilt die offizielle Freigabe von Teilschritten oder der finalen Version. Ist die finale Freigabe dann erfolgt, wird diese Version auf das eigentliche Produktionssystem (P) ausgerollt und den Kunden zur Nutzung bereitgestellt.
Durch diesen Staging-Prozess („auf die Bühne bringen“) ist es somit möglich, einen kontinuierlichen Entwicklungs- und Updateprozess durchzuführen, ohne dabei die Testaktivitäten oder das Produktionssystem zu stören oder im schlechtesten Fall sogar lahmzulegen. Dies gilt insbesondere für Updates von Drittanbieterkomponenten (z.B. Betriebssystem, Tools, Bibliotheken, Datenbanken, usw.), die einen wesentlichen Einfluss auf die Stabilität des Gesamtsystems haben können, aber nicht zwangsläufig von den verschiedenen Herstellern aufeinander abgestimmt sind. Welchen Einfluss diese auf das entwickelte System haben, lässt sich auf einem D-System gefahrlos vorab überprüfen. Sind alle Komponenten wieder aufeinander eingespielt, erfolgen Tests und Freigabe auf dem Q-System und schließlich das Deployment auf das P-System.
Ein Staging wird von Wibu-Systems auch beim Einsatz der CodeMeter License Central empfohlen. Steht ein Upgrade auf eine neue Version an, muss die grundsätzliche Kompatibilität des Gesamtsystems vorab getestet und freigegeben werden, ganz besonders wenn individuelle Erweiterungen für die CodeMeter License Central entwickelt wurden. Mit einem etablierten Staging-Prozess bestehend aus D-, Q-, und P-Linie ist das problemlos möglich. Wer den Aufwand der Installation und des Betriebs solcher Linien im eigenen Unternehmen scheut, kann diese Arbeiten auch in das zertifizierte Rechenzentrum von Wibu-Systems auslagern.
KEYnote 44 – Ausgabe Herbst/Winter 2022