DevOps

Dokumentationsrichtlinien für das DevOps sind wichtiger denn je

In der Computerwoche, vom 02.05.2018 - https://www.computerwoche.de/a/wie-devops-die-it-beschleunigen,3071433, wird treffend das Thema DevOps aufgegriffen und im Kern beschrieben. Ob es sich dabei um Methoden, Prozesse oder einen philosophischen Ansatz handelt (siehe dazu im Wikipedia: https://de.wikipedia.org/wiki/DevOps) soll hier nicht weiter vertieft werden, dazu gibt es schon Berichte zu Hauf.

Die zuvor aufgeführten Beschreibungen decken sich mit den Erfahrungswerten, die in unterschiedlichen Projekten in unterschiedlichen Unternehmen und Branchen gewonnen wurden.

Verschiedene Softwarehersteller (große und kleine) versuchen auf den „DevOps Zug“ aufzuspringen und vermarkten ihre bestehenden Softwarelösungen als die ultimative Softwarelösung, die offensichtlich schon immer DevOps unterstützt hat. Nun, grundsätzlich ist diese Aussage richtig und soll unbestritten bleiben. Diese Art der Softwareprodukte/-lösungen unterstützen den Anwender bei der Umsetzung eines professionellen „Deployments“ von der Entwicklung (engl: Development) bis hin zur Inbetriebnahme im IT Betrieb (engl: IT Operations). Dies allerdings nur bis zu einem gewissen Grad, denn dann bahnt sich der Interpretationsspielraum von DevOps seine eigenen Wege und der Dokumentationsanteil bleibt auf der Strecke - unberücksichtigt.

Das Dokumentationsthema zu DevOps ist eine Schwachstelle der unbedingt begegnet werden muss. Die Existenz der Schwachstelle lässt sich damit begründen, dass die Dokumentationserstellung rund um DevOps nicht allein der reinen Etablierung geschuldet ist, sondern den begleitenden Life Cycle Prozessen. Leider lässt sich das Thema nur schwer erfassen, weil es keine festen Bezugspunkte, wie beispielsweise Anwendungssoftware oder Hardware im klassischen Stil, aufweist.

Steigt der Betrachter tiefer in den technologischen Ansatz, kommt er zur Erkenntnis, dass die Umsetzung der DevOps Methodik (beschrieben mit dem ∞ Zeichen) lückenhaft ist, weil die reine Umsetzung von Entwicklungsarbeit bis hin zur Inbetriebnahme nur die eine Seite der Medaille ist. Die andere Seite der Medaille muss zwangsläufig in der lückenlosen Dokumentation der entwickelten bzw. der verwendeten Objekte hinsichtlich des Life Cycles enden. „Enden“ bedeutet hier nicht das Ende, sondern der Übergang in einen revisionsfähigen Zustand, einem echten Life Cycle Prozess.

Wie zuvor erwähnt, benutzen viele Softwarehersteller diesen technologischen und legitimen Ansatz, vernachlässigen dabei jedoch den Life Cycle eines Objekts für Unternehmensprozesse. Bei der Rückfrage beim Softwarehersteller wurde zwar bekundet, dass die erstellten Softwareobjekte sich dokumentiert im System einfinden, allerdings konnte niemand die Frage beantworten: „Wie die Anforderungen zuvor spezifiziert worden sind, bevor sie in den IT Betrieb überführt worden sind. Und ‚last but not least‘, wie Änderungen im Life Cycle Prozess auf das Gesamtprojekt wirken.“

Die Gründe liegen auf der Hand. Im DevOps Thema verbergen sich zwei Facetten, nämlich

• die eines Softwareherstellers und
• die einer begleitenden und revisionssicheren Dokumentation.

Der Softwarehersteller

Der Softwarehersteller entwickelt seine Objekte und lässt diese bis zur Inbetriebnahme reifen. Der typisch klassische Workflow ist dabei Entwicklungs-, Test-, QA- und Produktionsphase.

Die begleitende und revisionssichere Dokumentation

Die Dokumentation soll zum einen das Projekt begleiten und dokumentieren was genau entwickelt und in den IT Betrieb überführt wurde. Und zum anderen muss eine revisionssichere Dokumentation etabliert sein, die sowohl den Status-Quo als auch den gesamten Life Cycle der Objekte abbildet.

Der Life Cycle umfasst dabei folgende Parameter:

• Die klassische Dokumentation.
• Die Revisionsangaben.
• Das Löschen und Ändern von Objekten, um wiederkehrenden Anforderungen gerecht zu werden.
• Die gegenseitige Beeinflussung der entwickelten Objekte zueinander.
• Die Genehmigungsprozesse und deren Verfahren.

Das DevOps Regelwerk legt die Rahmenbedingungen fest, die für eine Dokumentationserstellung für beliebige Objekte notwendig sind. Das primäre Ziel ist, die Reduzierung von Entwicklungs- und Testaufwänden. Dies kann in erster Annäherung nur durch einen modularen Objektaufbau und die Sicherstellung einer Wiederverwendbarkeit bereits erstellter Objekte möglich ermöglicht werden.

In dem Regelwerk für DevOps Dokumente, wie beispielsweise einem „Style Guide“, werden Begrifflichkeiten wie

• die Automatisierung der IT Prozesse,
• die Wiederverwendbarkeit,
• die Modularisierung und
• der zentrale Einstiegspunkt

hervorgehoben. Dies gilt es im Regelwerk herauszuarbeiten, zu verfeinern und dem Anwender an die Hand zu geben, bevor Objekte in ein IT System gebracht werden. Dies soll einen Wildwuchs an unkontrollierten Objekten entgegenwirken.

In einschlägigen Softwareanwendungen werden vereinzelt DevOps Ansätze/Unterstützungen angeboten, die einen automatischen Auslieferungs- bzw. Verteilungsprozess ermöglichen. Es ist dabei festzuhalten, dass dies anwendungsbezogene Prozesse sind und in der Regel nicht anwendungsübergreifend anzuwenden sind (in den seltensten Fällen benutzt ein Unternehmen die Software desselben Softwareherstellers). Es sei hervorzuheben, dass das Ziel eines DevOps Regelwerks, eine homogene Auslieferungsprozessbeschreibung zu liefern, ist.

Für ein umfangreiches Cloud Projekt konnte ein DevOps Regelwerk erarbeitet und umgesetzt werden, das es ermöglicht gerade die angewandten DevOps Methoden zu dokumentieren und dabei in einem Life Cycle Prozess revisionsfähig abzubilden. Das DevOps Regelwerk berücksichtigt dabei sowohl die Objekt Versionierungen (Historienbetrachtung), als auch die Betrachtung der Wiederverwendbarkeit und Abhängigkeiten der entwickelten Objekte in den jeweiligen Anwendungen zueinander. Damit konnte einer Überfrachtung einer Serviceumgebung mit Altlasten entgegengewirkt und eine lückenlose Life Cycle Dokumentation mit Genehmigungsprozessen etabliert werden.

Die Vor- und Nachteile bei der Verwendung eines DevOps Regelwerks sind in der Tabelle wie folgt zusammengefasst:

Fazit:

Auch wenn es Nachteile aufzuzeigen gibt, werden diese durch die Vorteile und der damit verbundenen Folgekostenreduzierungen bei weitem wieder kompensiert.