DevOps@Work (Teil 2)

Nachdem wir im ersten Teil des Beitrags eher allgemeine Dinge geklärt haben, möchten wir euch im Folgenden zeigen, wie die Projektphasen gegliedert und strukturiert werden können. Diese Informationen sollen euch dabei helfen, ein Projektvorgehen für eure jeweilige IT-Organisation abzuleiten. Das Modell ist als Baukasten zu verstehen, der entsprechend eurer jeweiligen Situation angepasst werden kann.

Phase „Rahmenbedingungen schaffen“

Besonders wichtig ist die notwendige Anpassung der Unternehmens-IT-Strategie zur Definition und Festlegung einer individuellen DevOps-Vision. Hier muss jedes Unternehmen für sich selbst definieren, was unter DevOps verstanden werden soll und wie weit dies umzusetzen ist – etwa für produktionsferne oder produktionsnahe Umgebungen. Diese Definition muss dann gemeinsam zwischen Management, Fachbereich und IT (Dev & Ops) abgestimmt werden.

Ein weiterer Punkt, der beachtet werden sollte, ist die Ausstattung des Projektes mit „Budget und Handlungsvollmacht“ - unter anderem zur Erstellung und Anpassung der notwendigen Blueprints. Dieser Faktor wird oft nicht beachtet oder zumindest unterschätzt. Er ist aber in der Praxis einer der wesentlichen Schlüssel zum Erfolg. Erfahrungsgemäß existieren viele Blueprints, die das Projekt verlangsamen oder blockieren. Daher ist die Strategie „Einfach mal machen“ in vielen Fällen nicht verkehrt, denn alle unnötigen Blueprints werden in eine Schublade gelegt und Neue erstellt.

Solltet ihr es nicht bereits getan haben, ist spätestens in dieser Phase zu prüfen, ob eine DevOps-Einführung beziehungsweise ein entsprechender Technologiestack die erhofften Vorteile bringt. Sind beispielsweise die Bereitstellungszeiten von Software durch den IT-Betrieb mit bestehenden Softwareentwicklungsprozessen für aktuelle und zukünftige Unternehmensanforderungen bereits ausreichend, ist ein DevOps-Technologiestack nicht erforderlich.

Ein Schlüssel zum Erfolg ist die Definition von Coaching-Funktionen aus den Bereichen IT-Sicherheit und IT-Architektur. Das bedeutet, die Abteilungen, die in der Regel aus ihrer klassischen Rolle heraus die Hürden auferlegen oder gar blockieren, müssen in einer konstruktiven Art und Weise gemeinsam mit dem Projektteam die neuen Blueprints entwickeln. In der Praxis führt ein kooperatives Vorgehen zwischen Projekt und der Linien-IT zu den besten Ergebnissen.

Aufgrund einer suboptimalen Projektinfrastruktur gibt es bei Projekten oftmals schon Startschwierigkeiten:

Ein DevOps-Team arbeitet zum Teil an mehreren Orten mit geringen Mitteln zur Kollaboration – etwa zu wenig Teamraum oder Whiteboards. Ein großer Raum für das gesamte Team, der auch zu Show-Zwecken genutzt werden kann, damit Stakeholder und Interessierte auch an Teamevents teilnehmen können, ist in diesem Fall von großem Vorteil.

Ebenso schwierig ist es, Entwicklern adäquate Rechte zu geben – beispielsweise lokale Admin-Rechte auf ihren Entwicklungsrechnern. Ein weiterer Punkt sind mögliche Zugriffe auf Artefakt-Repositories im Internet. Viele Unternehmen sind darauf nicht vorbereitet und verlieren Zeit, bevor sie überhaupt ein Projekt begonnen haben. Im Vorfeld müssen also Grundlagen - etwa Netzzonen oder Zugriffswege und -rechte - existieren, die eine agile Entwicklung nicht behindern.

Außerdem sollten im Vorfeld adäquate Projektwerkzeuge bereitgestellt werden, damit das Team seine operative Arbeit aufnehmen kann. Dazu zählen ein Projektwiki wie Confluence und ein Planungstool wie beispielsweise JIRA.

Phase "Projekt planen"

Nachdem also die Rahmenbedingungen geschaffen wurden, beginnt in dieser Phase die eigentliche Projektplanung.

Wesentlich für die Planung ist die erste Definition eines initialen DevOps-Technologiestacks. Hier wird nämlich auf Basis von Anforderungen sowie unternehmensspezifischen Vorgaben und Besonderheiten ein erstes Set an Werkzeugen an den Start gebracht, das auf seine Nutzung im DevOps- Kontext geprüft wird. Wichtig ist, dass bei dieser Auswahl von Beginn an die Coaches aus den Bereichen IT-Sicherheit und IT-Architektur unterstützend zur Seite stehen. Im Verlauf der Sprints werden nach „Trial & Error“ entsprechende Werkzeuge geprüft und ausgewählt.

Im Rahmen der Projektorganisation hat es sich zudem bewährt, die Rolle eines DevOps-Coaches so zu definieren, dass er die Funktion als neutrale Instanz und Moderator ausübt. Der DevOps-Coach besitzt übergreifende Erfahrung aus Technologie und Softwareentwicklung, um Impulse zu liefern und um einen Kontext zu anderen Projekten herzustellen. Auf diese Weise kann ein Austausch und eine Vernetzung inner- und außerhalb des Projektes stattfinden.

Phase "Projekt durchführen"

In der Durchführungsphase wird dann der eigentliche Technologiestack aufgebaut. Dazu werden die notwendigen Blueprints erstellt und das DevOps-Team entwickelt und verifiziert Abläufe, um die Technologie erfolgreich einsetzen zu können. Es sollten unbedingt Vertreter des Managements und Interessierte eingeladen werden, damit diese sich einen persönlichen Eindruck vom agilen Vorgehen machen können. Falls Werkzeuge nicht gemäß der vorab geplanten Anforderungen oder Einsatzziele funktionieren, müssen diese angepasst oder durch andere ersetzt werden, bis alle festgelegten Kriterien erfüllt sind. Die Erfahrungen und Erkenntnisse sollten ab dem ersten Tag gut zugänglich und verständlich dokumentiert werden. Erfahrungsgemäß kann zum Beispiel der Einsatz eines Projekt-Wikis zum Erfolg beitragen.

Phase "Projekt abschließen"

Bei Abschluss des Projektes sind lediglich wenige Besonderheiten zu beachten. Bereits existierende Verfahren und Strukturen des klassischen Projektvorgehens reichen aus.

Wesentlich sind eine Definition und der Ablauf entsprechender technischer und fachlicher Tests:

• Test und Abnahme für den Aufbau einer neuen Betriebsplattform mit den dazu notwendigen Tests (Last & Performance, Failover, Recovery, etc.)
• Test und Abnahme der jeweiligen Releases, die später auf der DevOps-Plattform betrieben werden

Für beide Testformen müssen jeweils technische und fachliche Testfälle definiert werden. In jedem Fall sollte zuerst eine Testautomation umgesetzt werden, damit kein späterer Engpass entsteht.

Die Projektorganisation ist entscheidend

Die Projektorganisation für die Einführung eines DevOps-Technologiestacks ist entscheidend. Neben den bereits bekannten Strukturen und Beteiligten innerhalb des Technologieprojektes gibt es die Besonderheit, dass das Kernprojekt selbst typischerweise ein Entwicklungsprojekt ist:

• Coaching-Rolle von Governance & Compliance (IT-Sicherheit, Datenschutz, etc.)
• Coaching-Rolle aus der IT-Architektur und gegebenenfalls Unternehmensarchitektur
• Aktive Integration aus dem IT-Betrieb (als Coach für DEV und Projektteilnehmer)

Projektintegrationsszenarien – Was genau soll ein DevOps-Technologiestack tun?

Ein IT-Vorgehensmodell allein generiert keinen Mehrwert für ein Unternehmen. Schließlich muss es auch einen entsprechenden Einsatzweck beziehungsweise Projektscope dafür geben. Auch hier gilt: Weniger ist mehr. In der Euphorie der ersten kleinen Erfolge durch den Einsatz von DevOps finden sich Unternehmen oftmals in der Komplexitätsfalle wieder. Wie schnell Euphorie in Verzweiflung umschlagen kann, lässt sich erahnen. Um dieser Situation vorzubeugen, empfiehlt sich ein schrittweises Vorgehen, ausgehend von einem einfachen Szenario hin zu einem komplexen:

EASY: Die einfachste und gängigste Variante ist die Ablösung einer dedizierten Middleware-Komponente – dazu zählen zum Beispiel Applikationsserver. Vielfach existiert große, teure Software, deren Ablösung in eine schlankere und systemoffenere Lösung viele Vorteile bringt.

MODERATE: Aufbauend auf der EASY-Variante oder je nach festgelegtem DevOps-Commitment können auch mehrere Middleware-Komponenten abgelöst werden. Das ist übrigens auch als direktes Szenario denkbar.

COMPLEX: In dieser Variante werden ganze Anwendungen in die DevOps-Plattform überführt. Somit werden in dieser Stufe beispielsweise auch Datenbanken zusätzlich zu den genannten Komponenten migriert.

DevOps-Kernbotschaften

Die bisher gemachten Aussagen im DevOps-Kontext lassen sich in wenigen Kernbotschaften zusammenfassen. Jedes Unternehmen muss schon vor der Transformation – oder auch vor dem Einsatz von DevOps - die eigene und individuelle DevOps-Strategie entwickelt und festgelegt haben. DevOps wird auch in Zukunft die klassische IT nicht ersetzen, sondern eine zusätzliche Alternative in bestimmten Bereichen bieten.

Erst wenn dieser umfassende Ansatz wirklich verstanden und auch tatsächlich über alle Führungsebenen gelebt und dauerhaft unterstützt wird, kann DevOps die Innovationskraft der IT maßgeblich steigern. Diese zusätzliche Innovationskraft kann dann durch die Unternehmensführung dazu genutzt werden, den stetig wachsenden und sich verändernden Anforderungen in den Kerngeschäftsfeldern besser und schneller gerecht zu werden.

DevOps@Work Teil 1

Dieser Beitrag ist auch im Java Magazin (Ausgabe 3/2019) erschienen.