In einem anderen Beitrag habe ich mir Probleme bei Software-Deployment Prozessen angeschaut. Dort habe ich als Ergebnis herausgestellt, dass eine Reduzierung der Fertigungstiefe dabei hilft, Qualitätsschwächen zu vermindern. Unter Fertigungstiefe habe ich dort den Grad des manuellen Eingreifens verstanden. Hier noch einmal die Ergebnisse in der Übersicht:
- Deploymentprozesse sind mehr als „Copy to directory“
- Manuelle „Fertigungstiefe“ muss reduziert werden, um Qualität zu erhöhen
- Wiederholbarkeit erhöht Sicherheit
- “Continuous Integration” unterstützt
- Virtualisierung ergänzt bestehende Infrastrukturen durch hohe Wiederholbarkeit und Verlässlichkeit der erzielbaren Ergebnisse
Für einen Deployment-Prozess bedeutet dies, dass eine hohe Fertigungstiefe vorliegt, wenn alles (oder das meiste) manuell durchgeführt wird. Demgegenüber steht eine geringe Fertigungstiefe, wenn eigentlich alles automatisiert abläuft und eine Person lediglich zum Abschluss nochmal auf die Umgebung schaut, um zu kontrollieren, dass alles wie gewünscht geklappt hat. In diesem Kontext wäre anstelle von “Fertigungsstiefe” vermutlich “Automatisierung” der bessere Begriff gewesen.
Deployment-Skripte: write once – run often
Das im verlinkten Beitrag besprochene Team hat den Grad der Automatisierung dadurch erhöht. dass automatisiert ablaufende Deploymentskripte verwendet wurden. Diese haben den entscheidenden Vorteil: write once – run often.
Der Vorteil einer skriptgesteuerten Lösung: write once – run often.
Nun bieten solche Skripte einen unschätzbaren Vorteil: Solange sie die Umgebung nicht verändert, müssen die Skripte nicht wieder angefasst werden, sondern sind up-to-date.
Stehen allerdings größere Änderungen (d.h. mehr als reines Bugfixing an bestehendem Code oder nur kleinere Weiterentwicklungen) an, müssen auch die Deploymentskripte angepasst werden. Hier kommt ein neuer Fehlerfaktor ins Spiel, da die notwendigen Anpassungen nicht unbedingt korrekt durchgeführt werden. Die möglichen Probleme sind (unter anderem) folgende:
- Mitarbeiter kennen das Deploymentverfahren (noch) nicht oder nicht ausreichend –> Wissen
- Bei Änderungen an mehreren Stellen gehen einige verloren bzw. werden übersehen –> Flüchtigkeitsfehler
Das Problem, gerade bei größeren Deploymentskripten, besteht häufig in der Komplexität, die diese entwickeln. Gerade in der häufigen Nutzung (oder bei häfuigen Änderungen) gewinnen diese Skripte deutlich an Umfang. Hier ist es wichtig, die Komplexität weiter zu reduzieren.
Bei der Verwendung von Deployment-Skripten sollte kontinuierlich an eine Verringerung der Komplexität gedacht werden.
Artefakte für eine reduzierte Komplexität
Es gibt viele Möglichkeiten, die Komplexität einer Anwendung zu reduzieren. Die einfachste Möglichkeit ist dabei, Skriptteile in separate Dateien auszulagern. Aber reduziert das tatsächlich die Komplexität?
Die Komplexität wird, wie das Verb bereits andeutet, ausgelagert – also verschoben. Der Unterschied zwischen auslagern und verschwinden ist offenkundig: die Komplexität bleibt, wird aber nur an einen anderen Ort verschoben.
Ausgelagerte Komplexität ist nicht verringerte Komplexität
Ein Ausweg aus dem Dilemma stellt die Verwendung von Artefakten dar. Die Idee dabei ist, aus einem Skript Pattern heraus zu arbeiten. Ein Pattern ist ein wiederkehrendes Muster, also Tätigkeiten die immer wieder durchgeführt werden müssen. Alle Tätigkeiten, die zu diesem Pattern gehören, werden anschließend zu einem Artefakt zusammengefasst. Anschließend wird nur noch das Artefakt verwendet.
Ein Pattern ist ein wiederkehrendes Muster, also Tätigkeiten die immer wieder durchgeführt werden müssen.
Für die konkrete Anwendung Deployment kann man zum Beispiel folgende Pattern feststellen:
- Dateien mit der Endung .properties werden immer ins Verzeichnis XYZ kopiert
- Dateien mit der Endung .sql werden immer gegen eine Datenbank ausgeführt
- Dateien mit der Endung –service.xml werden immer das deploy-Verzeichnis des Applikationsservers kopiert
- Dateien mit der Endung .reg werden immer in die Windows Systemregistrierung eingetragen.
- Nach jedem Deployment wird die Anwendung XYZ gestartet
- …
Die Liste erhebt, wie üblich, keinen Anspruch auf Vollständigkeit und muss für den jeweiligen Anwendungsfall angepasst werden – aber ich denke, das Prinzip ist klar geworden.
Ein Pattern wird zu einem Ant-Task wird zu einem Artefakt
Für all diese Tätigkeiten kann man nun ant-Tasks schreiben (wenn man Apache Ant verwendet) die diese Funktionen durchführen und nur noch parametrisiert werden müssen. Dabei werden dann Dateien, Pfade oder Anwendungen/Skripte als Parameter mitgegeben, die dann in den Tasks verarbeitet werden.
Die Verwendung von Ant-Tasks verschleiert Komplexität und macht damit die Verwendung einfacher.
Werden diese Tasks verwendet, reduziert sich ein Skript auf das Aufrufen von eigenen Tasks. Jeder Task ist dabei für ein bestimmtes Artefakt zuständig und “weiß”, wie dieses Artefakt zu behandeln ist.
Der unschätzbare Vorteil für die Entwickler (in diesem Falle die Anwender der Software) ist dabei, dass sie nicht die ausgeklügelten Mechanismen hinter den Tasks kennen brauchen, sondern lediglich wissen müssen, was für ein Artefakt sie deployen wollen. Schon können Sie es verwenden.
Ant-Tasks reduzieren Komplexität und vereinfachen die Weiterentwicklung
Ein weiterer Vorteil, neben der einfacheren Verwendung ist die einfachere Wartung. Dadurch, dass man nur noch Tasks aufruft, können diese Tasks separat weiterentwickelt werden. Auf der anderen Seite müssen aber bei Weiterentwicklungen die bestehenden Skripte nicht angepasst werden, wodurch sich der Aufwand für Weiterentwicklungen reduziert: eine Win-Win Situation.
Die Ergebnisse habe ich nochmal in einer Mind-Map zusammengefasst:
Fazit
Die Verwendung von Deploymentskripten ist ein großer Schritt in die richtige Richtung. Durch die weitergehende Abstraktion des Vorgangs “Deployment” können aber weitere Verbesserungen eingeführt werden: Die Verwendung von Artefakten als Sammlung gleichartiger Arbeitsschritte vereinfacht die Verwendung dramatisch. Die Möglichkeit, diese Artefakte getrennt voneinander weiter zu entwickeln und die bestehenden Skripte nicht anpassen zu müssen, führen zu einer Win-Win-Situation in jedem Projektumfeld.