Blog-Reihe: „Houston, wir haben ein Problem“ (IT-Support. Teil 4)
Oxana MartevaiaIn den vorherigen Blog-Teilen haben wir schon den Entwicklungszyklus von Software-Services angesprochen, der üblicherweise über eine Kette von Testsystemen erfolgt. Das Stichwort hier lautet „Release- und Deployment-Management“, in dessen Rahmen die anstehenden Änderungen und Funktionserweiterungen geplant und überwacht werden.
Gewöhnlich werden einzelne Software-Komponenten zunächst in den niedrigen Testumgebunden, der CIT (Component Integration Test), auf ihre Funktionalität geprüft, bevor mehrere Komponenten in der nächsthöheren Testumgebung, der SIT (System Integration Test) auf ihr Zusammenspiel und ihre Wechselwirkungen untereinander getestet werden. Das Endprodukt der Entwicklung wird schließlich in dem UAT (User Acceptance Test) zusammen mit dem Auftraggeber auf Herz und Nieren geprüft, bevor die Freigabe durch den Abnehmer erfolgt und die Entwicklung in die Produktionssysteme übertragen werden kann.
Umfangreiche Softwareprojekte in Großunternehmen unterliegen einem eigens für deren Verwaltung eingerichtetem Release- und Deployment-Management. Dies bedeutet, dass nur zu bestimmten vorher festgelegten Zeiten neue Funktionalitäten auf den Produktivsystemen freigegeben werden, die sogenannten „Releases“. Das eigentliche Deployment, also das Einspielen von Software-Änderungen und erweiterten Funktionalitäten, wird gewöhnlich mit eigenen Management-Prozessen begleitet. Auch gibt es dezidierte Software-Tools, die das Deployment unterstützen und z.B. wichtige Funktionen, wie den automatischen „Roll-Back“ beinhalten, falls doch noch ein Fehler entdeckt werden sollte, der nicht im Test aufgefallen ist.
Softwareprojekte, die für mehrere zukünftige Releases parallel entwickelt werden, verwenden oft mehrere parallellaufende Ketten von Testsystemen, die nach erfolgreichem Release umgehängt werden. Ein solches Schema könnte wie folgt aussehen:
Kette 1 (unmittelbar nächstes Release): CIT1 -> SIT1 > UAT1 -> PROD
Kette 2 (übernächstes Release): CIT2 -> SIT2 -> UAT2
Kette 3 (über-übernächstes Release): CIT3 -> SIT3 -> UAT3
Nach erfolgreichem Release würde Kette 1 vom Produktivsystem abgekoppelt und stattdessen Kette 2 angekoppelt werden; Kette 1 kommt dann ans Ende hinter Kette 3 und stünde für ein weiteres geplantes Release zur Verfügung.
Änderungen am Produktivsystem, die nicht umfangreich genug sind, um im Rahmen eines regulären Releases freigegeben zu werden, also z.B. geringfügige Konfigurations- und Parameteränderungen oder das Verschieben des Zeitraums automatisch eingeplanter Prozesse, fallen unter das Change-Management. Mehr darüber erfahren Sie in der Fortsetzung nächste Woche.
Quellen:
http://wiki.de.it-processmaps.com/index.php/Release_und_Deployment_Management
Kommentare
Popular Posts
