Web Services: Deployment-Prozess

Jeder Server dürfte wahrscheinlich seine eigenen Konfigurationen erfordern. Dies kann man gut mithilfe seiner Source-Code-Repository-Anwendung in den Griff bekommen. Dazu erstellt man eine Konfigurationsdatei und anschließend separate Unterordner (für Entwicklung, Test und Produktion), so dass man dieselben Dateien mit unterschiedlichen Konfigurationen in jedem Ordner speichern kann. Da kann beispielsweise der String für die Datenbankverbindung in der Web.config-Datei je nach Server unterschiedlich sein, so dass man für jeden Server eine separate Web.config-Datei in jedem Konfigurations-Unterordner speichern würde.

Die hier erstellten Build-Deployment-Scripts haben bewusst die Web.config-Datei ausgelassen, da diese in 99 Prozent der Fälle nicht für alle Server gültig ist. Sobald das Build erstellt ist, muss man nur noch die korrekten Konfigurationsdateien aus dem Repository für den entsprechenden Server entnehmen.

Sobald die Konfigurationsänderungen vorgenommen wurden, kann das gesamte Build zusammengezippt und auf den Produktions-/Test-Server überspielt werden. Dort wird es sofort in die korrekten Ordner entpackt. Einer der Vorteile von ASP.NET ist, dass man Live-Updates durchführen kann, ohne die Anwendung zu beeinträchtigen.

Auf ein Problem ist der Autor allerdings gestoßen: Falls sich die Assemblies geändert haben, wird der ASP.NET Worker-Prozess neu gestartet, so dass alle bestehenden Benutzer-Sessions verloren gehen. Dies sollte zwar nicht der Fall sein, es kommt aber vor.

Nach dem Update des Produktions-/Test-Builds werden die neuen Assemblies und Web.config-Dateien in die .NET-Laufzeitbibliothek geladen. Es empfiehlt sich immer, das System einer einfachen Funktionsfähigkeitsprüfung zu unterziehen um sicherzustellen, dass die Anwendung auch wie erwartet läuft.