Ein Gastartikel von Sebastian Schramm.

„Wenn am Freitag bzw. am Wochenende die Software ausgerollt wird, dann kommen wir am Montag prinzipiell erst mittags. Vorher funktioniert sowieso nichts!“

Diesen Satz habe ich 2015 zu Beginn eines Projektes gehört und er begleitet mich seither bei meiner täglichen Automatisierungstätigkeit, speziell im Bereich Software-Entwicklung und Bereitstellung.

Viele Unternehmen wollen ihre IT automatisieren, scheitern jedoch schon an der Definition, was genau Automatisierung für sie bedeutet.

Automatisierung des IT-Betriebs ist sehr vielschichtig und reicht von automatisierter Hardware-Bereitstellung, über Software-Verteilung bis hin zur klassischen Software-Entwicklung, die durch Software wie Broadcom’s CDA (Continuous Delivery Automation, früher ARA) agiler gemacht wird.

In diesem Beitrag erkläre ich, was ein Software-Rollout überhaupt ist und warum Sie dabei eine Automatisierung brauchen.

Definition: Was ist ein Software-Rollout?

Beginnen wir mit einer trockenen Definition.

Ein Software-Rollout ist ein Unternehmensprozess, bei dem durch Koordination und einen strukturierten Ablauf neue Software auf einer großen Anzahl Clients verteilt wird.

Soweit die Theorie.

Es gehört aber mehr zum Software-Rollout: die Abstimmung von Software-Abhängigkeiten, Benutzerschulungen und Tests. Diese Aspekte werden häufig bei einer Deployment-Automatisierung vergessen.

Die praktische Erfahrung zeigt, dass es bei Rollouts oft an Struktur und Koordination mangelt. Auf meine Nachfrage, wo denn der Ablaufplan hinterlegt sei, antwortete mir ein User: „Der liegt in unseren Köpfen. Nur wir wissen, was zu tun ist, das kann man nicht automatisieren“.

Ich behaupte das Gegenteil. Dank CDA kann man diesen Prozess automatisieren. Dafür muss man nur vier kleine Fragen beantworten.

Die Grundlagen: Automatisierung mit 4 kleinen Fragen

Die vier Fragen lauten schlicht Wer?, Was?, Wie? und Wohin?.

Die Antworten auf diese Fragen müssen Sie natürlich nicht in Excel-Tabellen verwalten, dafür haben Sie CDA. Dort gibt es sogenannte Entitäten, die genau diese Elemente eines Rollouts beinhalten. Mit CDA können Sie alle Informationen zentral in einer Technologie bündeln.

Ihre Mitarbeiter erhalten durch CDA Zugang zu einer grafischen Modellierungsoberfläche, wo sie ihr  implizites Wissens abbilden können. Wer jetzt befürchtet, dadurch werde der Mitarbeiter überflüssig, liegt falsch: Seine Aufgabe ist jetzt die Standardisierung und Modellierung der Unternehmensabläufe.

Mit CDA können Sie also jeden Ablauf grafisch modellieren und für alle transparent machen. Dadurch verbessern sich sowohl Effizienz als auch Auditfähigkeit in Ihrem Unternehmen.

So sind die notwendigen Bestandteile eines Software-Rollouts strukturiert.

 

Nun aber zurück zu den Fragen.

  1. Wer führt den Rollout aus?
    Die Frage nach dem Ausführenden lässt sich leicht beantworten. Ausgeführt wird die Operation von einem beliebigen Anwender – sei es jemand aus dem IT-Betrieb oder Ihr zentraler Release-Koordinator. Das eigentliche Software-Deployment wird in CDA von technischen User-Accounts ausgeführt, die in den Login-Objekten hinterlegt sind. Sie können so durch die Vergabe von Berechtigungen Verantwortung dezentralisieren.
  2. Was wird überhaupt ausgerollt?
    Das ist natürlich Ihre Software. Dabei ist es gleich, ob Sie ein Code-Repository  benutzen oder eine zentrale Ablage haben. Die Software besteht aus mehreren Software-Komponenten (z. B. Konfigurationsdateien, Software-Artefakten oder Betriebshandbüchern) deren Release-relevante Informationen im Package hinterlegt werden. Allerdings dient das Package nicht als Ablageort für Software-Artefakte (Code- und Artefakt-Verwaltung mit CDA schauen wir uns vielleicht in einem anderen Artikel noch genauer an), sondern lediglich als Informationsspeicher. Die Ablage erfolgt weiterhin an einem Ort Ihrer Wahl.
  3. Wie läuft der Rollout ab?
    Hierbei handelt es sich um das Herzstück des CDA-Systems. Mit dem „Wie“ wird der Workflow verknüpft. Der Workflow ist die technische Abbildung Ihres strukturierten Ablaufs bei der Bereitstellung von Software. Um Struktur und Inhalt des „Wie“ geht es in den letzten beiden Abschnitten dieses Artikels.
  4. Wohin findet der Rollout statt?
    Kernelement dieser Dimension ist das Deployment Profile, eigentlich eine Umgebungsdefinition. Es setzt sich zusammen aus Umgebung (Environment), zugehörigen Servern (Deployment Targets) und dem Login-Objekt mit den Anmeldeinformationen für die technischen User. Durch die Verbindung der genannten Informationen erhalten Sie auch gleich ein Konfigurationsmanagement, da Sie anschließend prüfen können, wer wann welche Software wohin ausgerollt hat. Typischerweise nutzen Unternehmen externe Tools für das Konfigurationsmanagement, das ist aber nicht zwingend erforderlich. Die Informationen für einen Software-Rollout müssen in diesem Fall vor der Durchführung mühsam zusammengetragen und an Ihr Automatisierungstool übergeben werden, was zu zusätzlichen Prozesskosten führt.

Überblick über die 4 Fragen und ihre korrespondierenden Entitäten.

Das A und O der Automatisierung: der Workflow

Als aufmerksamer Leser denken Sie sich jetzt bestimmt: „Aber da fehlen doch noch mehr Objekttypen?“. Ich kann Sie beruhigen, im letzten Abschnitt werden wir alle verbliebenen Objekte besprechen.

Zunächst aber zum Workflow.

Zur Kapselung aller Software-relevanten Informationen – z. B. des Software-Titels, spezifischer Konfigurationen und der Beschreibung der Software-Komponenten – wurde die Application geschaffen. Sie ist wie alle anderen Entitäten ein leerer Datencontainer, der erst durch Anreicherung mit Ihrem Wissen lebendig wird.

Analog zu Ihrer Software, die aus mehreren Bestandteilen, wie z. B. einer Server-Applikation, einer Datenbank und einem Client besteht, lassen sich mit einer Application mehrere Components verknüpfen. Die elementare Regel ist, dass jede Component immer nur zu einer Application gehört. Jede Application muss und kann einzeln beschrieben werden. Da in vielen Unternehmen die Applikationen jeweils kleine Unterschiede aufweisen, ist die Steuerung an dieser Stelle sehr realitätsnah.

Jetzt kommt natürlich die berechtigte Frage auf: „Was hat das mit dem Workflow zu tun?“ Die Antwort ist: „Alles!“

Alle zuvor beschriebenen Objekttypen sind Teil der Workflow-Struktur. Der Workflow teilt sich in drei Ebenen ein:

  • Application Workflow (besteht aus 1 bis n Component Workflows)
  • Component Workflow (besteht aus 1 bis n Action Workflows)
  • Action Workflow

Die Beziehung zwischen Application Workflow, Component Workflow und Action Workflow.

Wie in Hollywood: „…und Action“

Das letzte Puzzle-Teil beim Aufbau Ihrer Deployment-Automatisierung sind Actions, in früheren Versionen auch Runbooks genannt. Actions sind kleine, in sich geschlossene Funktionen, die für exakt eine Aufgabe konzipiert sind. Betrachtet man beispielsweise typische Operationen auf einem Filesystem, so lassen sich Actions, wie „Datei kopieren“, „Verzeichnis kopieren“, „Verzeichnis löschen“ oder auch „Bash Skript ausführen“ als einzelne Actions definieren.

Mithilfe der Actions können Sie Ihre Automatisierung des Deployments bis aufs kleinste Detail abbilden, da Sie sowohl Standard-Actions vom Marketplace nutzen, als auch selbst welche erstellen können. Sie haben die völlige Freiheit – Sie sind Herrscher über Ihre eigene Automatisierung!

Schluss mit der Theorie: ein Beispiel

Es wird Zeit, einen solchen Workflow an einem Beispiel zu verdeutlichen, finden Sie nicht auch?

Wir sehen uns den Ablauf eines Filesystem-Updates beim Software-Rollout an.

Nehmen wir an, Sie wollen Ihr Verfahren „SportsWearShop“, einen Online-Shop für Sportbekleidung, neu ausrollen. Sie legen also einen Datencontainer vom Typ Application an. Anschließend definieren Sie eine Component von der Typdefinition „Server“ (ein Online-Shop ist ja typischerweise eine Web-Applikation).

Unterhalb der Application erstellen Sie einen Workflow und fügen im Editionsmodus eine Instanz der Component hinzu.

Diese Instanz öffnen Sie dann und fügen Ihre Actions Schritt für Schritt hinzu.

In unserem Beispiel sehen die Actions folgendermaßen aus: Zunächst alte Datenarchive löschen, anschließend derzeitige Daten archivieren, gewünschte neue Datenstruktur anlegen, neue Dateien auf das Filesystem transferieren und schließlich überschüssige oder temporäre Verzeichnisse löschen.

Visualisierung eines Workflows für den Software-Rollout bei einem Filesystem-Update.

Natürlich können Sie einen solchen Prozess auch ohne CDA durchführen und sich auf jahrzehntealte Skripte und die Erfahrungen Ihrer Mitarbeiter verlassen. Aber CDA veranschaulicht Ihnen Ihre Automatisierung, unterstützt die Mitarbeiter und bietet gleichzeitig viel Flexibilität. Das merken Sie spätestens bei der Fehlersuche, wenn Ihnen die integrierte Farbsteuerung auf einen Blick zeigt, wo Ihre Automatisierung hängt. Keine stundenlange Suche in Skripts mehr, keine Mutmaßungen und keine Kopfmonopole. Sie können jederzeit Ihre Automatisierung im Hintergrund ändern, neue Technologien einführen oder das Personal neu strukturieren – das Tool lässt Sie auf jede Änderung reagieren.

Ausblick

Der vorliegende Blogbeitrag war eine Art Aperitif auf die Möglichkeiten der Automatisierung mit CDA. Ich habe noch einige weitere Ideen, um aus diesem Artikel eine kleine Serie zu machen: Spezielle Action Packs vorstellen, Continuous Integration und Continuous Delivery Pipelines, die Abbildung von Prozessabläufen in Ihrem Unternehmen und vieles mehr.

Interessieren Sie diese Themen? Dann schreiben Sie mir doch einen Kommentar oder eine E-Mail.

Und denken Sie immer daran, dass der Automatisierung mit CDA keine Grenzen gesetzt sind – oder wie es im Automic-Slogan so schön heißt: Let’s automate your Business!

Sebastian Schramm

Trainer für Automic-Produkte

Sebastian Schramm ist Entwickler, Berater und Trainer für Automic Produkte. Er unterstützt Sie dabei, Ihre Automatisierung im Unternehmen zu stärken – nicht nur bei Automic Produkten, sondern auch vielen anderen Prozessen und Technologien. Seine Leidenschaft ist die DevOps-Automatisierung.

ChefCoach IT GmbH

Wir sind ein Team festangestellter IT-Experten und unterstützen Sie mit unserem Spezialwissen in Ihren IT-Projekten. Da wir weder Hard- noch Software vertreiben, können wir Sie herstellerunabhängig beraten. Wir setzen unsere Erfahrung ein, um mit Ihnen das bestmögliche Konzept für Ihr Projekt umzusetzen. Sie profitieren durch unsere langjährige Erfahrung von einem kompetenten Expertenteam.