L I C E N S I N G
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 un- abhä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 .
9