In fast jedem Softwareprojekt wird die Applikation auf mehrere Server mit unterschiedlichen Konfigurationseinstellungen installiert und betrieben. Neben der Konfiguration für die Produktivumgebung müssen auch die Konfigurationen für Staging- und Entwicklungsserver verwaltet werden. Beispielsweise benötigt die Staging-Instanz andere Datenbankeinstellungen als die Produktivinstanz.
Somit kommen bei einem Projekt schnell mal 6 Konfigurationsversionen zusammen:
- dienstleister-devlocal (lokale Entwicklungsinstanz)
- dienstleister-dev (zentrale Entwicklungsinstanz)
- dienstleister-sta (Staging System beim Dienstleister)
- kunde-sta (Staging System beim Kunden)
- kunde-productive1 (Produktiv-System – Cluster 1)
- kunde-productive2 (Produktiv-System – Cluster 2)
Jede Konfigurationsversion setzt sich aus einer Vielzahl von Dateien zusammen, die sich noch in unterschiedlichen Pfaden befinden. Wenn zudem noch ein Produkt einsetzt wird, (z.B. Day Communiqué oder Hybris) kommt man leider ab und an in die Verlegenheit Dateien des Produktes (z.B. JavaScripts) zu überschreiben. Weiteres Beispiel ist die Installation von DLLs (z.B. bei Verwendung des SAP JCO Connectors).
Das Problem ist: Manuelles Pflege auf allen Servern ist langsam, fehleranfällig und nicht zuletzt unglaublich langweilig. Die Lösung ist recht simpel: Automatisieren, Automatisieren, Automatisieren, Automatisieren… Dabei trennt man das Projekt strickt von den eigentlichen Konfigurationsdateien. Diese Trennung spiegelt sich auch im Subversion wieder.
Beispiel Projekt im Subversion:/project<br /> /project/core/branches<br /> /project/core/tags<br /> /project/core/trunk<br />
Beispiel Konfiguration im Subversion:/project_configuration<br /> /project_configuration/branches<br /> /project_configuration/tags<br /> /project_configuration/trunk<br /> /project_configuration/trunk/scripts<br /> /project_configuration/trunk/instance/dienstleister-devlocal<br /> /project_configuration/trunk/instance/dienstleister-dev<br /> /project_configuration/trunk/instance/dienstleister-sta<br /> /project_configuration/trunk/instance/kunde-sta<br /> /project_configuration/trunk/instance/kunde-live1<br /> /project_configuration/trunk/instance/kunde-live2<br />
Auf jedem Server wird /project/core
und /project_configuration
ausgecheckt. Aber wie kommen Konfiguration und Projekt zusammen ? Dies geschieht über ANT-Skripte, die aus einem ausgecheckten Projekt eine lauffähige, serverabhängige Installation generieren. Dabei werden die Dateien aus dem jeweiligen Konfigurationsverzeichnis (z.B. dienstleister-devlocal
) in das Projektverzeichnis kopiert und ggf. vorhandene Dateien überschrieben.
Somit kann in wenigen Minuten eine komplette Instanz installiert werden. Weiter vereinfacht wird das Ganze, wenn .bat Dateien (oder Shellscripte) diese ANT-Skripte aufrufen.
Beispiel Skriptaufruf:
checkout-project-configuration.bat
(Checkt das Konfigurationsprojekt aus dem Subversion)
checkout-project.bat
(Checkt das Projekt aus dem Subversion aus)
configure-dienstleister-devlocal.bat
(Konfiguriert das Projekt mit “dienstleister-devlocal” Konfiguration)
Fazit:
Durch das Automatisieren sämtlicher Konfigurations- und Installationsdateien werden Flüchtigkeitsfehler vermieden und das Aufsetzen von Serverinstallationen erheblich beschleunigt. Das Programmieren solcher Konfigurationsskripte kostet zwar zu Beginn des Projekts etwas Zeit, diese Investition wird aber doppelt und dreifach wieder amortisiert.