Web Services: Deployment-Prozess

Sind die beiden Demo-Anwendungen für unser Fallbeispiel (siehe vorausgegangene Artikel) vollständig implementiert, kann man daran gehen einen Deployment-Prozess zu entwerfen, um die Anwendungen in eine Produktionsumgebung zu überspielen. Hierbei soll der prinzipielle Perspektivenwechsel beleuchtet werden, der erforderlich wird, sobald eine Anwendung in eine Produktionsumgebung gebracht wird. Außerdem geht es um die Entwicklung von Deployment-Scripts, um Produktions-Builds zu einer reibungslosen Angelegenheit zu machen.

Vorausgegangene Artikel

1. Web Services: Entwicklung eines Szenarios
2. Web Services B2B-Implementierung: Komponenten, Ausnahme-Behandlung und Logging
3. Web Services: Datenbank-Design
4. Implementierung der Business-Logik
5. Implementierung von B2B Web Services: Toms Anwendung
6. Web Services: Johns ASPX GUI-Schicht
7. Web Services: Umsetzung einer ASPX GUI-Schicht

Entwicklung, Testen, Produktion

Hier sollen noch einmal einige allgemeine Entwicklungsprinzipien in Erinnerung gerufen werden. Die meisten Entwickler sind mit den Begriffen Entwicklung, Testen und Produktion im Kontext eines Entwicklungszyklus’ vertraut. Jeder dieser Begriffe steht für eine unterschiedliche Ebene des Entwicklungsprozesses, wobei die Entwicklung der erste, das Testen der zweite und die Produktion der letzte Schritt des Zyklus’ ist.

Es ist der Entwicklungszyklus, in dem die Anwendung Gestalt annimmt. Hier werden Anforderungen und Anwendungsfälle in Dokumentation und Code-Implementierungen übersetzt. Leider hinterlässt der Entwicklungsprozess häufig viele Lücken oder Bugs und/oder nicht erfüllte Anforderungen, was einen Test- oder Qualitätssicherungs-Zyklus (QS) notwendig macht.

Der Test-Zyklus ist eine Vor-Produktions-Umgebung, die in jedem Fall die Konfiguration der tatsächlichen Produktionsumgebung widerspiegeln sollte. Damit hat das QS-Team die Möglichkeit, die Anwendung in einer simulierten Produktionsumgebung zu testen, ohne dass echte Produktionsdaten davon betroffen sind. Das QS-Team durchläuft einen festgelegten Prozess, bei dem Features und Bugs entdeckt werden, und speist alle Probleme in ein System zur Konfliktlösung ein.

An diesem Punkt gibt es eine Rückkopplungsschleife im Prozess: Alle Bugs, die in das Konfliktlösungs-System eingegeben wurden, werden an den Entwickler zurückgegeben und der Prozess beginnt wieder bei Schritt eins. Es können mehrere Test-Builds erforderlich sein, ehe das QS-Team mit dem Zustand der Anwendung zufrieden ist und die Zustimmung gibt, diese Version in die Produktionsumgebung zu überführen.

Sobald die Anwendung für produktionsreif gehalten wird, findet normalerweise eine Übergabe mit einer operativen Abteilung statt, die für das Aufspielen des Builds vom Test-Server auf den Produktionsserver verantwortlich ist. Hierbei kann es noch zu kleineren Änderungen kommen, die auf Differenzen bei Konfigurationsparametern zwischen den beiden Servern zurückzuführen sind. Üblicherweise wird ein Dokument mit Release-Hinweisen für die Kunden oder andere Teams innerhalb des Unternehmens erstellt, so dass die vorgenommenen Änderungen transparent sind.

Es sollte alles Menschenmögliche unternommen werden um sicherzustellen, dass das für die Produktionsumgebung freigegebene Build stabil und frei von schwer wiegenden Bugs ist. Man stelle sich nur einmal einen Bug vor, der die Daten verfälscht, aber dem QS-Team entgeht. Dieser Fehler könnte zu einem Umsatzverlust für Tausende von Kunden oder zu irreparablen Schäden an der Datenbank führen. Die Bedeutung eines stabilen Produktions-Builds kann nicht oft genug hervorgehoben werden.