Development, Operations, Contunuous Delivery, Continuous Deployment, Agil, Lean, Team, Qualitätssteigerung, Infrastructure as a Code

Wachs­tum meis­tern: DevOps – Teil II

Teil 1: Defini­tion und Mo­ti­va­tion
Teil 2: Veränderungen als unverzichtbare Basis
Teil 3: Herausforderungen und Risikofaktoren
Teil 4: DevOps in der Praxis

Die Kultur fruchtbarer gestalten

Neben Tools zur Arbeitserleichterung und Automatisierung ist eines der zentralen Wesensmerkmale von DevOps, dass die Entwicklungs- und Operations-Teams nicht mehr isoliert voneinander arbeiten, sondern kooperieren.

Um für ein Unternehmen diesen Mehrwert zu schaffen, ist zunächst einiges an Vorarbeit zu leisten. Die wichtigste Methode dabei ist ein Wandel in Kultur und Kommunikation. DevOps fordert regelrecht, dass Teams oder Mitarbeiter flexibel und eng miteinander agieren, die von Natur aus häufig konträre Ziele verfolgen. Während beispielsweise die Mitarbeiter aus der Entwicklung Systeme fortwährend verändern und möglichst wenig Zeit für Sicherheitsmanagement aufwenden möchten, wünscht sich der Bereich Operations eher eine stark kontrollierte Softwareentwicklung mit klar beschriebenen Veränderungen, da diese oft Produktionsrisiken darstellen. Die Kreativität und Flexibilität in der Entwicklung scheinen dem Wunsch nach Stabilität und Verfügbarkeit im Betrieb vielfach konfliktträchtig gegenüberzustehen. Hier Kooperation zu schaffen, erfordert folglich zunächst einen Kulturwandel.

Von einem solchen Wandel profitieren Projekt und Kunde. Denn wenn zwischen Mitarbeitern teamübergreifend Vertrauen und wenig Konkurrenzdruck besteht, neigen sie eher dazu, Informationen offen zu kommunizieren. Mit der Selbstverpflichtung der Akteure, sich auf gemeinsame und nicht persönliche Ziele zu fokussieren, fällt dieser Schritt einfacher. Des Weiteren ist eine Selbstverständlichkeit immens wichtig, die leider nicht immer selbstverständlich erscheint: Es sollte Gerechtigkeit und Verständnis herrschen. In agilen Projekten müssen einige Mitarbeiter kalkulierte, strategische Risiken eingehen dürfen. Wer schnell handeln möchte, muss aus Zeitgründen Erwägungen abkürzen. Das birgt Chancen auf Innovationen, aber es birgt ebenfalls Risikopotential für Fehler. Doch in der Regel profitieren die Unternehmen eher von engagierten kreativen Mitarbeitern, die Verantwortung übernehmen und sich dabei gelegentlich Fehler erlauben, als von Mitarbeitern, die besorgt sind wegen negativer Konsequenzen oder Maßregelungen. Die Unternehmen schaffen so eine produktive Kultur des Lernens, der Gewissenhaftigkeit und des Innovationseifers.

Prozesse automatisieren

Dieser Kulturwandel setzt Einsatz und vorbildliches Verhalten von oben voraus. Das alleine wird jedoch eher selten große Veränderungen nach sich ziehen. Kommen angepasste Prozesse hinzu, fällt es Mitarbeitern hingegen einfacher, in respektvoller und offener Kultur zusammenzuarbeiten.

Klassische Modelle für Softwareentwicklung sind hier eher unvorteilhaft. Sie unterteilen den Entwicklungsprozess in Phasen oder funktionale Einheiten innerhalb eines Lebenszyklus. Dabei beginnt der Zyklus üblicherweise mit der Problemstellung auf Kundenseite und endet mit der Übergabe an den Kunden. Dazwischen finden sich beispielsweise beim Wasserfallmodell grob die Schritte Anforderungsanalyse, Systemdesign und Spezifikation, Entwicklung, Testen und Ausliefern. Anschließend übernimmt der Lieferant oft noch die Wartung.

Softwareerstellung Softwaredevelopment
In klassischen Modellen, wie dem Wasserfallmodell erfolgen die einzelnen Schritte aufeinander folgend. Eventuelle Fehlentwicklungen werden im Vergleich zu DevOps oft zu spät erkannt.

Nach diesem Modell würde eine Anwendung möglichst vollständig entwickelt, getestet, überprüft und anschließend in die Produktivumgebung migriert werden. Die einzelnen Schritte erfolgen demnach eher aufeinanderfolgend in einzelnen Teams. Hierbei erschweren Konflikte teils die Übergaben zwischen den funktionalen Einheiten. Der Grund dafür ist, dass sich häufig die Infrastruktur und die Toolchain in den einzelnen Teams unterscheiden. Zudem haben Operations-Mitarbeiter in dem Modell wenig Einfluss auf die Entwicklung der Anwendungen, müssen aber nach Auslieferung die Sicherheit und Stabilität verantworten. Die einzelnen IT-Mitarbeiter vertreten zudem häufig lediglich den eigenen Abteilungshorizont, was selten zu der Optimierung des Gesamtprozesses und der Software beiträgt. Die Folge sind Interessenkonflikte, Hin- und Herschieben von Verantwortlichkeiten sowie Unzufriedenheit auf Seite des Kunden.

Bei DevOps hingegen wird dieser Ablauf aufgebrochen und verzahnt. Es gibt einzelne Sub-Teams, in denen jeder Verantwortung übernimmt. Wie einzelne Module in einem Baukasten werden Teams in einer optimalen Zusammenstellung gebildet. Mal kleine, mal große, mal für kurze Zeiträume, mal für längere. Entscheidend sind die unterschiedlichen Kompetenzen und Fähigkeiten (Skillsets) der einzelnen Spezialisten.

Development, Operations, Contunuous Delivery, Continuous Deployment, Agil, Lean, Team, Qualitätssteigerung, Infrastructure as a Code
Im DevOps-Team sollten bei jedem Mitarbeiter sowohl genügend Spezialwissen als auch fachübergreifendes Wissen vorhanden sein.

Jedes Teammitglied sollte über Spezialwissen (Wissenstiefe) verfügen, aber auch ein Generalist sein. Neben Wissenstiefe sollten folglich genug Knowhow-Schnittpunkte (Wissensbreite) vorhanden sein, um sich flexibel im Projekt einzusetzen und die Stufen vor und nach den eigenen zu verstehen. So entsteht eine crossfunktionale bzw. funktionsübergreifende Kommunikation und Mitarbeit. Die enge Zusammenarbeit und neue Kultur fordert einerseits diese Wissensbreite, gleichzeitig wird die Wissensbreite durch DevOps verbessert. Ein gesunder Kreislauf der Optimierung, eingebunden in agile Prozesse.

Development, Operations, Contunuous Delivery, Continuous Deployment, Agil, Lean, Team, Qualitätssteigerung, Infrastructure as a Code
Für Softwareentwicklung im DevOps-Team ist Wissenstiefe notwendig. Für eine optimale Zusammenarbeit im Team zudem Wissensbreite um fachübergreifende Themen nachzuvollziehen.

Die neue offene Kultur und Kompetenz der Mitarbeiter wirft die klassischen Entwicklungsmodelle für Softwareentwicklung über Board. Bei DevOps-Teams transportieren kooperierende Mitarbeiter aus unterschiedlichen Bereichen die Projekte nicht mehr auf langen und langsamen Fließbändern mit Übergangsgrenzen, bis sie beim Kunden als Gesamtpaket ankommen. Sie erstellen in dynamischer Zusammenarbeit überschaubare kleine Systembausteine und liefern so in kürzester Zeit kleine Erfolgspakte, die dem Kunden direkt einen Mehrwert bieten und Fehlentwicklungen rechtzeitig erkennen lassen.

Development, Operations, Contunuous Delivery, Continuous Deployment, Agil, Lean, Team, Qualitätssteigerung, Infrastructure as a Code
Die optimale Mischung aus Wissenstiefe und Wissensbreite ermöglicht eine crossfunktionale und dynamische Zusammenarbeit, in der Fehlentwicklungen rechtzeitig erkannt werden

Hilfsmittel für Automatisierung

Um dies schnellstmöglich in sicherer Qualität zu ermöglichen, müssen viele manuelle, sich wiederholende Prozesse automatisiert und infrastrukturelle Schnittstellen beseitigt werden. Softwarestandards und Automatisierungen gekoppelt mit agilen Lean-Methoden realisieren eine zügige Einführung und Anpassung von Anwendungen. Zudem ermöglicht die Automatisierung redundanter Einzelprozesse die schnelle Auslieferung von Teilpaketen. Hier kann der Kunde, der genaue Vorstellungen über das gewünschte Ergebnis hat, zeitnah interagieren und auf eine eventuelle Fehlentwicklung hinweisen. In klassischen Wasserfallmodellen geschieht dies in der Regel erst nach der Gesamtfertigstellung. Zudem fördern automatisierte und standardisierte Abläufe die Innovationsfähigkeit. Mitarbeiter müssen sich einerseits nicht mehr mit redundanten Aufgaben aufhalten und andererseits werden eventuelle Fehler, die bei schnellem und innovativem Vorgehen wahrscheinlicher werden, rechtzeitig erkannt und beseitigt. Die DevOps-Teams arbeiten nach Verfahren wie Continuous Integration, Continuous Delivery, Continuous Deployment etc. um Bereitstellungen, Entwicklungs- und Test-Workflows, Container-Verwaltung und Konfigurationsverwaltung zu automatisieren.

Continuous Integration

Als Continuous Integration wird der automatisierte Prozess bezeichnet, der den aktuellen Stand der Software aus dem Code Repository auswählt und alle Komponenten zusammenfügt (Integration). Sehr häufig stehen Softwarekomponenten in Abhängigkeit zueinander (Dependency). Doch in der Entwicklung können manche dieser Abhängigkeiten fehlen (z.B. ein E-Mail-Server, oder GPS Empfänger der Daten liefert etc.). Damit die Entwicklung dennoch diese berücksichtigt, werden Abhängigkeiten simuliert oder abstrahiert (Mock-up und Decoupling). Mit dem so genannten Build werden die Komponenten automatisch zusammengetragen und vordefinierte Tests durchgeführt. Einen reibungslosen und schnellen Ablauf ermöglicht der Continuous Integration Prozess, wenn bei jeder Codeänderung im Programmcode (change commit) automatisch der Build und Integrationstest im Hintergrund durchgeführt wird. Der Entwickler bekommt unmittelbar mitgeteilt, ob seine Codeänderung erfolgreich war. War sie es nicht, kann er direkt auf Fehlermeldungen reagieren.

Continuous Delivery

Continous Delivery kann als eine Erweiterung von Continuous Integration gesehen werden. Die Software ist über den gesamten Lebenszyklus hindurch deploybar. Hierbei können alle Teams ihre Aufgaben so priorisieren, dass ihre Software sich immer in einem auslieferungsfähigen Zustand befindet. Das geschieht durch konsequentes und schnelles Feedback über den Build-Prozess. So können Codeänderungen im Build eingeschlossen und in einer oder mehreren dedizierten Umgebungen automatisch getestet (System Integration Test, Performance Test etc.) und für eine Produktionsversion bereitgestellt werden.

Continuous Deployment

Continuous Deployment beschreibt die automatische Bereitstellung der Softwarepakete in einer Produktionsumgebung. Dies stellt eine hohe Hürde auf, da ein erfolgreicher Build nach strengen Kriterien getestet werden muss. Auch die Stabilität und Sicherheit des Softwarepakets muss vollkommen automatisch geprüft werden, um Entscheidungen direkt und ohne manuelle Eingriffe zu treffen. Continuous Deployment darf nicht verwechselt werden mit Release Management. Dieser Ansatz ist wesentlich umfangreicher und deckt die einzelnen Mehrwert liefernden Phasen der Release-Zyklen von der Planung hin bis zum Go-Live ab. Wird jedoch nach der agilen Methode und Continous Deployment gearbeitet, entfallen einige Aufgaben des Release Managements, da ein Großteil des Verwaltungsaufwandes überflüssig wird.

Automatisierte Prozesse sind für die schnelle Auslieferung sicherer Software-Produkte unabdingbar
Microservice Architecture

Microservice Architecture ist ein Architekturmuster (Design Pattern) für Client-Server Applikation. Es erlaubt den modularen Aufbau komplexer Anwendungssoftware mit Hilfe von unabhängigen Komponenten (bzw. Services oder Diensten) die durch Application Programming Interface (APIs) angebunden werden und miteinander kommunizieren.

Infrastructure as Code (IaC)

Für all die Automatisierungsschritte darf eine reibungslos funktionierende Infrastruktur als existentielle Basis nicht fehlen. Infrastructure as Code bietet die Möglichkeit, manuelle Prozesse zu automatisieren und Infrastruktur zugeschnitten bereitzustellen. Auch als programmierbare Infrastruktur bezeichnet, ermöglicht IaC die Konfiguration und Verwaltung von Servern und Umgebungen, auf denen die Dienste ausgeführt werden. Von Vorteil ist, dass neben der Entwicklerumgebung weitere Umgebungen, wie Systemintegrationsumgebung, User Acceptance Umgebung und Produktionsumgebung simuliert werden. Das hat zur Folge, dass bei DevOps die Anwendungen zunehmend Skripte enthalten, in denen die virtuellen Maschinen und Umgebungen mit abgebildet sind. Das größtenteils cloud-basierte Fundament wird dadurch besonders flexibel, schnell, skalierbar und kosteneffektiv. Zudem entspricht der Grundgedanke von IaC dem von DevOps: Eigentlich nicht zusammenhängende Bereiche werden gebündelt, da nun der Entwickler ebenfalls für die Infrastruktur zuständig ist.

Neuorganisation mit agilen Methoden und Lean Management

Neben Tools zur Automatisierung ist die Anpassung der organisatorischen Prozesse ein entscheidender Baustein. Die Softwarequalität kann in kürzeren Release-Zyklen nur verbessert werden, wenn die Prozesse nach Lean-Management ablaufen.

Die Vorstellung, die Produktion schlank zu halten, hat den Ursprung in der japanischen Automobilproduktion. Dabei sollen die drei Bereiche der Verschwendung unterbunden werden: Muda: Arbeit, die dem Produkt keinen Wert hinzufügt; Muri: Überlastung von Mitarbeitern und Maschinen und Mura: Unregelmäßigkeit der Prozesse.

Beachtenswert sind in erster Linie zwei Methoden, welche schlanke Prozesse fördern sollen: Scrum und Kanban.

Kanban

Kanban, was im Japanischen in etwa Signalkarte bedeutet, wurde anfänglich verwendet, um insbesondere in der Produktion flüssig nach dem Just-in-Time-Prinzip arbeiten zu können. Mit Hilfe der Signalkarten wurde von einer Produktionsabteilung in eine Vorangestellte kommuniziert, dass Material benötigt wird. So wurde weder Überschuss produziert noch gab es, auf Grund von fehlendem Material, Unterbrechungen.

Kanban ist neben Scrum ein häufig verwendetes Modell um die Prozesse in DevOps Projekten zu optimieren.
Kanban ist neben Scrum ein häufig verwendetes Modell um die Prozesse in DevOps Projekten zu optimieren.

Dieses Prinzip findet inzwischen auch in der Softwareentwicklung Verwendung. Angelehnt an die agilen Lean-Prinzipien, arbeiten die Mitarbeiter nach dem Hol-Prinzip. Sie werden nicht von oben angewiesen, den nächsten Produktionsschritt anzugehen, sondern verwenden das Kanban-Board, um sich zu informieren, wann sie an einem Projekt weiterarbeiten können. Das Kanban-Board hilft hierbei, indem es den aktuellen Stand des Projektes visualisiert. Es bietet im selbstregulierenden Kanban-System eine übersichtliche Darstellung, welche Hürden im Prozessablauf aufzeigt.  Diverse Aufgaben oder Work-Items und deren jeweiliger Arbeitsstatus im Projekt können direkt eingesehen werden. Das Kanban-Board dient ebenfalls zur Kapazitätsabschätzung. Wird im aktuellen Stand ein Stau durch zu viele stockende Abläufe signalisiert, kann beispielsweise durch Ressourcenerweiterung oder Prozessoptimierung eingegriffen werden. Der zentrale Gedanke gilt dabei dem Arbeitsfluss, der nicht unterbrochen werden darf.

Scrum

Das Prinzip Scrum erinnert beim Definitionsversuch an die Prinzipien von DevOps, denn Projekte werden in kleinen, sich selbstorganisierenden, bereichsübergreifenden Teams erarbeitet. Die Kernmerkmale von Scrum bilden

  • fünf Aktivitäten (Product Backlog Refinement, Sprint Planning, Daily SCRUM, Sprint Review, Sprint Retrospective),
  • drei Artefakte (Product Backlog, Sprint Backlog sowie Product Increments) und
  • drei Rollen (Product Owner, Scrum Master und Team).
Sprint, Product Owner, Product Backlog
Klar definierte Rollen, schnelle Einsetzbarkeit, eine einfache Struktur und ein selbstorganisiertes Entwicklerteam sind die sind die Hauptgründe für den Erfolg von Scrum.

Das Scrum-Modell ist als Lean-Methode aus der Erfahrung entstanden, dass viele Entwicklungsprojekte zu umfangreich und zu komplex sind, als dass sie sich direkt zu Projektstart vollständig mit allen Anforderungen und Lösungsansätzen in einen Plan pressen lassen. Es gibt zwar einen umfassenden Plan (Product Backlog), dieser erhebt jedoch nicht schon zu Beginn den Anspruch auf Vollständigkeit und wird erst mit der Zeit verfeinert. Hilfestellung geben hier die Zwischenergebnisse aus den überschaubaren Sprints. Sie und die festen Meetings, an denen alle Projektteilnehmer regelmäßig teilnehmen, bilden eine wichtige Konstante zwischen den Teammitgliedern. Unter Sprint versteht man die einzelnen Schritte in der Produktentwicklung, welche maximal vier Wochen dauern dürfen. In den wöchentlichen gemeinsamen Terminen werden Sprints vereinbart und Projektabläufe reflektiert. Schriftlich festgehalten werden die Anforderungen in Product- und Sprint-Backlogs, sowie einem Scrum-Board, das vergleichbar ist mit einem Kanban-Board. Bei all den Anforderungen ist es auch bei kleineren Teams sinnvoll, einen Scrum-Master festzulegen, der die Abläufe und die Kommunikation nach außen organisiert.

Kanban und Scrum im Vergleich

Nun stellt sich die Frage, welches Modell eher geeignet ist, DevOps umzusetzen. Schon die grobe Übersicht über die beiden Modelle zeigt, dass Scrum einen höheren Koordinierungsaufwand mit sich bringt. Dieser lohnt sich erfahrungsgemäß eher bei größeren Projekten, wenn beispielsweise mehr als vier Softwareentwickler beteiligt sind. Scrum beschreibt im geordneten Rahmen getaktete und strukturierte Abläufe, um Schritte zu synchronisieren und den Austausch anzuregen. So wird meist stark darauf geachtet, dass der Kunde in den Entwicklungsprozess eingebunden ist. In sehr kleinen Teams geschieht ein reger Austausch in der Regel ohnehin von alleine. Die größeren Teams profitieren im Arbeitsablauf von verbindlich festgelegten Terminen, Strukturen, Verantwortlichkeiten und Regeln. Aber die Konzentration auf einzelne Schritte verbessert nicht nur die Zusammenarbeit und die Entwicklungsprozesse, sondern ebenfalls das Entwicklungsprodukt, welches nicht von Anfang an klar definiert sein muss. Der Umfang kann im Entstehungsprozess flexibel angepasst werden. Dennoch kann die Skalierbarkeit des Projektumfangs an ihre Grenzen stoßen, da die Funktion des Product Owners, der als Schnittstelle zum Kunden fungiert, zum Flaschenhals werden kann.

Im Gegensatz zu Scrum ist Kanban besonders gut geeignet für Projekte, bei denen die Projektziele bereits klar spezifiziert werden können. Auch zeigt Kanban seine Stärke, wenn die jeweiligen Mitarbeiter an mehr als einem DevOps Projekt gleichzeitig arbeiten. Die Kanban-Boards geben einem Mitarbeiter trotz mehrerer paralleler Projekte eine schnelle Übersicht über Aufgaben und deren Dringlichkeit. Zudem bietet Kanban eine gute Lösung, wenn im Unternehmen größere Veränderungen oder Eigenverantwortung nicht erwünscht sind. Auch wenn die Projektmitarbeiter dazu neigen, viele Projekte zu beginnen aber wenige abzuschließen, bietet Kanban eine gute Orientierung. Darüber hinaus hat sich diese Methode bewährt bei kleineren Teams oder wenn die Rollen der Teammitglieder stark spezialisiert und nicht ersetzbar sind.

Die Frage, welche Methode geeigneter für DevOps ist, kann dennoch nicht starr beantwortet werden. Es hängt schließlich von Verantwortlichen und weiteren Agierenden ab, welche Methode auf mehr Zuspruch stößt. Während manch einer die klaren Vorgaben und die zahlreichen Verbindlichkeiten vorzieht, um Projekte sicher und schnell durchzuschleusen, fühlt sich manch anderer eher zu einem Konzept mit weniger Verwaltungspflichten hingezogen.

Teil III: Welche konkreten Herausforderungen anstehen, um die Weichen zu stellen, soll im nachfolgenden Teil betrachtet werden.

Katy Spalek

Katy Spalek

Manager Corporate Publishing bei BROCKHAUS AG
Katy Spalek ist bei der BROCKHAUS AG als Redakteurin für die Bereiche Marketing und Vertrieb zuständig und verantwortet Recherche, Verfassen und Layout von Texten zur Kundenkommunikation. Für das blogHAUS verfasst sie Beiträge über aktuelle Trendthemen aus IT, Marketing und Wirtschaft.
Katy Spalek
<< Vorheriger Beitrag
Nächster Beitrag >>

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.