Die acht Phasen einer DevOps-Pipeline

Wenn man über DevOps spricht, ist es sinnvoll, den Prozess in Phasen zu unterteilen, die zusammen eine DevOps-Pipeline ergeben. Auf diese Weise können die Tools und Prozesse, die in den verschiedenen Phasen verwendet werden, aufgeschlüsselt und beschrieben werden.

Verschiedene Leute werden ihr Skalpell ansetzen, um die Pipeline an verschiedenen Stellen zu zerschneiden, andere wiederum eine Liste von Phasen erstellen. Das Ergebnis beschreibt in der Regel dasselbe. Wichtig ist nur, dass die Terminologie innerhalb Ihrer Organisation konsistent ist, damit alle das gleiche Verständnis über die Prozesse haben.

Dieser Artikel beschreibt die achtstufige DevOps-Pipeline und definiert dabei auch einige andere Begriffe, die üblicherweise verwendet werden, wenn über DevOps gesprochen wird.

Die acht Phasen einer DevOps-Pipeline sind in dem Bild des “DevOps-infinity-loop” sehr gut visuell dargestellt.

Im Folgenden wird genauer auf die einzelnen Phasen eingegangen.


Planen

Die Planungsphase umfasst alles, was passiert, bevor die Entwickler anfangen, Code zu schreiben. Hier sind ein Produkt- oder Projektmanager gefragt. Anforderungen und Feedback werden von Stakeholdern und Kunden gesammelt und zur Erstellung einer Produkt-Roadmap verwendet. Die Produkt Roadmap kann mit einer Vielzahl von Tools geplant, dokumentiert und nachverfolgt werden um u.a. den Projektfortschritt, Probleme und Meilensteine aufzuzeigen. Etablierte Tools sind z.B. Jira, Azure DevOps, oder Asana. Sie kann in Epics, Features und User Stories unterteilt werden, wodurch ein Backlog mit Aufgaben entsteht, die direkt zu den Anforderungen der Kunden führen. Die Aufgaben im Backlog können dann verwendet werden, um Sprints zu planen und dem Team Aufgaben zuzuweisen, um mit der Entwicklung zu beginnen.

Code

Das Entwicklungsteam kann an die Arbeit gehen sobald das erste Epic bis zu den User Stories und Features durchgeplant ist. Früher hat man erst alles durchgeplant (Lastenheft/Pflichtenheft) und dann komplett an die Entwicklungsabteilung gegeben. Was häufig eine lange Verzögerung zur Folge hatte, bis mit der Umsetzung gestartet werden konnte. Heute legt die Entwicklung los sobald der erste Abschnitt geplant ist und parallel werden weitere Epics und Userstories geplant. Feedback von den Entwicklern oder Usern die die ersten Module Testen konnten, kann dann schon berücksichtigt werden für weitere Epics.
Zusätzlich zum Standard-Toolkit eines Softwareentwicklers hat das Team einen Standardsatz von Plugins in ihren Entwicklungsumgebungen installiert, um den Entwicklungsprozess zu unterstützen, ein konsistentes Code-Styling zu erzwingen und häufige Sicherheitslücken und Code-Anti-Patterns zu vermeiden.
Dies hilft, den Entwicklern gute Programmierpraktiken beizubringen und unterstützt gleichzeitig die Zusammenarbeit, indem es für eine gewisse Konsistenz in der Codebasis sorgt. Diese Werkzeuge helfen auch bei der Lösung von Problemen, die später in der Pipeline bei Tests auftreten können, was zu weniger fehlgeschlagenen Builds führt.

Build

In der Build-Phase kommt DevOps erst richtig zum Tragen. Sobald ein Entwickler eine Aufgabe abgeschlossen hat, übergibt er seinen Code an ein gemeinsames Code-Repository. Ein anderer Entwickler überprüft dann die Änderungen, die gemacht wurden. Wenn das Review der Sourcen erfolgreich ist und es keine Probleme gibt, wird der Push-Request genehmigt. Diese manuelle Überprüfung soll schnell und leichtgewichtig sein, um Probleme effektiv und früh zu erkennen.
Gleichzeitig löst der Push-Request einen automatisierten Prozess aus, der die Codebasis baut und eine Reihe von End to End-, Integrations- und Unit-Tests durchführt, um alle Regressionen zu identifizieren. Wenn der Build oder einer der Tests fehlschlägt, schlägt der Push-Request fehl und der Entwickler wird benachrichtigt, damit das Problem gelöst werden kann. Durch die kontinuierliche Überprüfung von Code-Änderungen in einem gemeinsam genutzten Repository können durch die Ausführung von Builds und Tests Integrationsprobleme minimiert werden, die bei der Arbeit an einer gemeinsam genutzten Codebasis auftreten. So können Fehler frühzeitig im Entwicklungslebenszyklus aufdeckt werden.

Test

Sobald ein Build erfolgreich war, wird er automatisch in einer Staging-Umgebung für tiefer gehende Tests bereitgestellt. Bei der Staging-Umgebung kann es sich um einen vorhandenen Hosting-Service handeln oder um eine neue Umgebung, die im Rahmen des Bereitstellungsprozesses zur Verfügung gestellt wird. Diese Praxis der automatischen Bereitstellung einer neuen Umgebung zu diesem Zeitpunkt wird als Infrastructure-as-Code (IaC) bezeichnet und ist ein Kernbestandteil vieler DevOps-Pipelines.

Sobald die Anwendung in der Testumgebung bereitgestellt ist, wird eine Reihe von manuellen und automatisierten Tests durchgeführt. Bei den manuellen Tests kann es sich um traditionelle User Acceptance Testing (UAT) handeln, bei denen Mitarbeiter die Anwendung des Kunden verwenden. Dadurch können Probleme oder Verbesserungen aufgezeigt werden, die vor dem finalen Deployment in die Produktionsumgebung behoben werden sollten.
Welche Tests in dieser Phase durchgeführt werden, hängt vom Unternehmen ab und davon, was für die Anwendung relevant ist. Diese Phase kann als Testumgebung betrachtet werden, in der Sie neue Tests einfügen können, ohne den Fluss der Entwickler zu unterbrechen oder die Produktionsumgebung zu beeinträchtigen.

Release

Die Release-Phase ist ein Meilenstein in einer DevOps-Pipeline: Es ist der Punkt, an dem ein Build bereit für den Einsatz in der Produktionsumgebung ist. Zu diesem Zeitpunkt hat jede Codeänderung eine Reihe von manuellen und automatisierten Tests durchlaufen – und das Betriebsteam kann sich sicher sein, dass danach keine Probleme mehr auftreten.
Je nachdem, wie weit sich ein Unternehmen im DevOps-Prozess befindet, kann es sich dafür entscheiden, jeden Build, der diese Phase der Pipeline erreicht hat, automatisch bereitzustellen. Entwickler können Schalter verwenden, um neue Funktionen abzuschalten, damit diese innerhalb der Anwendung nicht sichtbar sind bevor sie einsatzbereit sind.
Mit Hilfe dieses forteschrittenen DevOps-Modells schaffen es Organisationen, täglich mehrere Releases ihrer Produkte bereitzustellen.
Alternativ kann eine Organisation auch die Kontrolle darüber haben wollen, wann Builds für die Produktion freigegeben werden. Sie möchten vielleicht einen regelmäßigen Release-Zeitplan haben oder neue Funktionen nur dann freigeben, wenn ein Meilenstein erreicht wurde.
Dazu kann man einen manuellen Genehmigungsprozess der Freigabephase hinzufügen, der es nur bestimmten Personen innerhalb einer Organisation erlaubt, eine Freigabe für die Produktion zu autorisieren.

Deploy

Schließlich ist ein Build bereit für die Freigabe zur Produktion. Es gibt verschiedene Tools und Prozesse, die den Freigabeprozess automatisieren können, damit die Freigabe zuverlässig und ohne Ausfallfenster erfolgt.

Dieselbe Infrastructure-as-Code (IaC), mit der die Testumgebung erstellt wurde, kann für die Erstellung der Produktionsumgebung konfiguriert werden. Da bekannt ist, dass die Testumgebung erfolgreich erstellt wurde, ist sichergestellt, dass auch das Produktionsrelease reibungslos ablaufen wird.

Ein Blue-Green-Deployment lässt uns ohne Ausfall auf die neue Produktionsumgebung wechseln. Dann wird die neue Umgebung gebaut, die neben der bestehenden Produktionsumgebung installiert wird. Wenn die neue Umgebung fertig ist, leitet der Hosting-Service alle neuen Anfragen an die neue Umgebung weiter. Und falls zu irgendeinem Zeitpunkt ein Problem mit dem neuen Build auftritt, können Sie die Anfragen einfach zurück auf die alte Umgebung leiten, während Sie eine Lösung finden.

Operate

Das neue Release ist nun live und wird vom Kunden genutzt. Dabei arbeitet das Betriebsteam daran, dass alles reibungslos läuft. Basierend auf der Konfiguration des Hosting-Dienstes skaliert die Umgebung automatisch die Last, um Spitzen und Tiefpunkte anhand der Anzahl der aktiven Benutzer zu bewältigen.

Um die Weiterentwicklung des Produkts zu unterstützen, wird anhand einer Feedbackschleife die Möglichkeit geschaffen, Feedback zum Service zu geben, sowie ein Tool bereitgestellt, das dabei hilft, dieses Feedback zu sammeln und auszuwerten. Denn niemand kennt die Anforderungen besser als der Kunde selbst – das beste Testteam der Welt sozusagen, das viel mehr Stunden für das Testen der Anwendung aufwendet, als es die DevOps-Pipeline je könnte.

Monitor

Die “letzte” Phase des DevOps-Zyklus ist die Überwachung der Umgebung. Diese baut auf dem Kundenfeedback aus der Operate-Phase auf, indem sie Daten sammelt und Analysen zum Kundenverhalten, zur Leistung, zu Fehlern und mehr liefert.

Es kann jetzt auch ein wenig Selbstbeobachtung betrieben werden und die DevOps-Pipeline selbst überwacht werden, indem nach potenziellen Engpässen in der Pipeline gesucht wird, die die Produktivität der Entwicklungs- und Betriebsteams beeinträchtigen könnten.

All diese Informationen werden dann an den Produktmanager und das Entwicklungsteam zurückgegeben, um den Kreislauf des Prozesses zu schließen. Es wäre einfach zu sagen, dass hier der Kreislauf wieder beginnt, aber die Realität zeigt, dass dieser Prozess kontinuierlich ist. Es gibt keinen Anfang und kein Ende, sondern nur die kontinuierliche Entwicklung eines Produkts während seiner Lebensdauer.

DevOps umfasst Ansätze, wie eine Idee von der Entwicklung bis zum Einsatz in der Produktivumgebung beschleunigt werden kann, um dort zur Wertschöpfung beizutragen. Diese Ansätze erfordern eine regelmäßige Kommunikation zwischen Entwicklungs- und Operations-Teams sowie eine gute Zusammenarbeit.

Weiterführende Informationen

Bleiben Sie auf dem Laufenden

Sie möchten mehr zum Thema erfahren?

Ich stehe Ihnen gern für weitere Fragen zur Verfügung.