Es gibt manchmal Momente, in denen man die eigenen Prozesse hinterfragt und sich darüber Gedanken macht, wie man Aufgaben besser erledigen kann. So ist es kürzlich auch mir ergangen.

Konkret ging es dabei um den Release-Prozess einer Software-Komponente. Zunächst sollte ich eventuell klarstellen, was ich mit dem schon beinahe überladenen Wort Release-Prozess meine. Der Release-Prozess umfasst aus meiner Sicht all jene Aufgaben, die ein Entwickler oder ein Unternehmen durchführen muss, um Software in dessen Anwendungsgebiet einsatzbereit zu machen. Insofern beinhaltet ein Release also im Kern das Erstellen des Kompilats der Anwendung, die Paketierung aller notwendigen Dateien zum Betrieb der Anwendung, den Transport des Installationspaketes auf die Einsatzumgebung und schlussendlich die Installation und Konfiguration der Anwendung auf dem Zielsystem. Ich möchte meine Ideen und Vorstellungen zu einem besseren Release-Prozess festigen, indem ich einzeln die Schritte eines Releases beschreibe.

Natürlich beinhaltet ein Release einer Software auch einige weitere Maßnahmen als die oben genannten, wie z. B. die Erstellung oder Aktualisierung von Dokumentationen oder Benachrichtigungen über die Verfügbarkeit der neuen Anwendungsversion bei der jetzigen Anwendern bzw. potentiellen Zielgruppen. Ich möchte hier allerdings nur auf den Kern des Release-Prozesses eingehen.

Erstellen des Release-Builds
Der wichtigste und aus meiner Sicht kritischste Punkt im Release-Prozess erfolgt gleich zu Beginn: Das Erstellen des Release-Builds. Hier ist es für ein sauberes Release entscheidend, dass von vornherein Richtlinien zu diesem Schritt vorhanden sind und beachtet werden. Die wichtigsten Regelungen sind meiner Meinung nach:

• Der Build ist automatisch.
  Folglich erfolgt er komplett automatisch, es ist keine Interaktion zum Bauen des Builds erforderlich.
• Der Build ist integer.
  Er beinhaltet alle Dateien, die zum Kompilieren der Software notwendig sind. Darüber hinaus enthält der Build alle Dateien, die zum reibungslosen Einsatz der Software auf dem Zielsystem erforderlich sind.
• Der Build ist atomar.
  Der Build wird demnach an einem festgelegten Zeitpunkt erstellt und wird während sowie nach dem Release-Prozess nicht mehr modifiziert.
• Der Build ist final.
  Er wird während des Release-Prozesses nur ein einziges Mal erstellt.

Paketierung der Software
Nach erfolgreicher Erstellung des Builds ist der nächste Schritt die Paketierung. Mit der Paketierung werden neben dem Kompilat alle weiteren Dateien wie zum Beispiel Release Notes, Benutzerdokumentation, Anwendungsbeispiele und ähnliches zu einem Gesamtpaket zusammengeschnürt. Hier ist vor allem die Art der Paketierung entscheidend. Im Allgemeinen sollte das Gesamtpaket mit einer Installation und Installationsanweisungen ausgeliefert werden. Leider kommt es in einigen Unternehmen noch viel zu oft vor, dass das Paket ein einfaches ZIP-Archiv ist. Wie beim Build-Schritt auch, sollten bei der Paketierung einige Grundregeln beachtet werden:

• Die Paketierung erfolgt automatisch.
  Es sind keine manuellen Schritte bis auf das Anstoßen der Paketierung erforderlich.
• Die Paketierung erfolgt erst nach erfolgreicher Abnahme des Release-Builds.
  Dies wird im Allgemeinen durch automatisierte Tests und manuelle Verifikation auf Testsystemen gewährleistet.
• Die Paketierung ist integer und final.
  Wie beim Build selbst wird das Auslieferungspaket nur einmal erstellt und während des Paketierungs-Prozesses nicht mehr modifiziert.
• Das Auslieferungspaket ist unabhängig.
  Unabhängig bedeutet in diesem Fall, dass das Paket keine weiteren Komponenten oder Informationen mehr benötigt, um auf dem Zielssystem installiert werden zu können.

Der letzte Punkt bedeutet natürlich nicht, dass man keine Komponenten auf dem Zielsystem voraussetzen sollte. Jede Software hat bestimmte System Requirements. Es soll vielmehr verdeutlichen, dass die Systemvoraussetzungen klar definiert werden sollten und außerhalb dessen keine weiteren Komponenten mehr erforderlich sind. Besonderen Wert auf Betonung lege ich beim letzten Punkt auf „Informationen“. Damit möchte ich zum Ausdruck bringen, das dass Installationspaket (außer den mitgegebenen Informationen) idealerweise keinerlei weiteres Wissen erfordert um es auf dem Zielsystem zu installieren und die Software in Betrieb zu nehmen.

Deployment
Der dritte elementare Schritt im Release-Prozess ist der Transport des Software-Paketes auf die Anwendungsumgebung. Je nach Art und Quantität der Software kann dieser Verteilungs- bzw. Distributionsprozess viele verschiedenartige Formen und Schritte beinhalten. Dennoch lassen sich bei aller Varianz einige allgemeine Aussagen treffen:

• Die Funktionalität der Distribution muss vor der eigentlichen Verteilung verifiziert sein.
  Konkretisiert ist hier der Test und die Abnahme des gesamten Verteilungsverfahrens gemeint, undzwar noch bevor es zum offiziellen Deployment der Pakete kommt.
• Das Ziel – also alle bekannten Betriebsumgebungen – muss noch vor der Verteilung klar definiert und anvisiert sein.
  Dies kann auf vielfältige Art und Weise erfolgen, zum Beispiel mit einer automatischen Update-Funktion auf den Zielsystemen. Klar muss hier jedoch die Menge, Arten und idealerweise auch die Positionen der Zielumgebungen sein.
• Das Deployment muss beweisbar sein.
  Damit wird sichergestellt, dass das Installationspaket die Zielumgebung auch definitiv erreicht hat. Schlussendlich ist damit die Sicherstellung der Bedienung des Kunden der Software gemeint.

Installation & Inbetriebnahme
Der finale Schritt im Release-Prozess ist die Inbetriebnahme der Software auf dem Zielsystem. Auch hier sind abhängig von der Art und dem Einsatzgebiet der Software viele unterschiedliche Maßnahmen möglich. Doch wie auch im Deploymentschritt können über diesen letzten Schritt auch generelle Punkte zur Beachtung aufgeführt werden:

• Die Installation und Konfiguration muss nachvollziehbar sein.
  Im Detail heißt das: Die Installationsroutine sowie auch die gesamte Grundkonfiguration der Software muss protokolliert werden. Bei der Installation ist dies bei Verwendung geeigneter Installationssoftware nicht sonderlich aufwendig. Etwas komplizierter wird es beim Konfigurieren der Software. Es kann sich hier als einen ausgesprochenen Vorteil erweisen, einen guten Konfigurationsassistenten für die Software anzubieten.
• Die Installation und Konfiguration muss reversibel sein.
  Man mag vielleicht im ersten Augenblick denken, das sei selbstverständlich. Der Alltag beweist leider oftmals das Gegenteil. Vor allem bei Installationen von neuen Versionen einer Software, welches im Unternehmensumfeld wesentlich öfter vorkommt als im privaten Bereich, sind bei manchen Softwareherstellern deutliche Defizite erkennbar.
• Die korrekte Durchführung aller Schritte zur Inbetriebnahme muss überprüfbar sein.
  Konkret: hat man alles richtig gemacht, sollte im Idealfall der Kunde als auch der Hersteller darüber informiert sein. Es versteht sich fast von selbst, dass hiermit auch die Rückmeldung an den Hersteller gemeint ist, wenn es nicht gut gelaufen ist.

Abschließend bleibt mir eigentlich nur festzustellen, dass meine hier aufgezeigte, allgemeine Vorstellung eines Release-Prozesses doch noch in manchen Punkten von der Realität abweicht. Ergo: Es ist höchste Zeit, Änderungen in Gang zu bringen .