DevOps Grundlagen (2/2): Phasen und Prozesse

Wie Sie bereits in unserem ersten Post gelernt haben, fügt DevOps auf Basis von agiler Arbeitsweise, Automatisierung und Cross-funktionaler Zusammenarbeit die bisher verteilten Aufgaben und Rollen im Unternehmen zusammen, sodass eine gemeinsame Basis der Wertschöpfung besteht. Dies bedeutet, dass die vorher auf die Entwicklungs- und Betriebsteams verteilten Aufgaben nun einem Kernteam zugeordnet werden und immer wieder durchlaufen werden. Man spricht deshalb vom sogenannten „DevOps Lebenszyklus“.

Welche Phasen durchläuft ein Projekt mit DevOps?

Die Phasen, die in diesem Zyklus durchlaufen werden, werden oft unterschiedlich benannt – je nach dem, mit welcher Person man spricht – am Ende verfolgen diese aber das immer das gleiche Ziel: den Gesamtprozess in kleinere Teilstücke und Phasen unterteilen, damit die Planung und Durchführung einfacher zu verstehen ist. Hierbei sollte aber erwähnt werden, dass es sich bei DevOps um einen geschlossenen, kontinuierlich fortlaufenden Prozess handelt und die hier beschriebenen Phasen fließend ineinandergreifen.

Plan

Die Planungsphase umfasst alles, was vor der eigentlichen Entwicklung des Programmcodes passiert. Im Zentrum steht hier eine Roadmap, die zur Planung der Umsetzung von Anpassungen am Produkt dient. Grundlage dieser Änderungen können sowohl User-Feedback, als auch interne Anforderungen sein. In einem modernen Tool, mit welchem eine DevOps-Pipeline abgebildet wird, werden aus diesen Artefakten dann Epics, Features und User Stories. Aus diesen werden dann Sprints geplant, Tasks abgeleitet und die nächste Phase vorbereitet. Tools zur Planung von Aufgaben sind z.B. JIRA, Redmine, oder EasyRedmine.

Code

Sobald die Aufgaben zugewiesen sind, machen sich die Entwicklungsteams an die Arbeit und erstellen den eigentlichen Programmcode. Fortschritte werden in regelmäßigen Meetings (Standups und Sprint Reviews) an das Team kommuniziert. Damit alle Entwicklungsteams einheitlich arbeiten, gibt es eine gemeinsame Basis für Tools und Plugins sowie einheitliche Vorgaben für Code-Qualität. Neben einer IDE zum Schreiben des Codes wird in dieser Phase ein Tool zum SourceCode-Management wie z.B. SCM-Manager benötigt. Außerdem können Wikis wie Confluence oder >Smeagol bei der Dokumentation des Codes helfen.

Build

Sobald eine Aufgabe abgeschlossen ist, wird der Code an ein zentrales Repository übergeben. Durch diesen sogenannten Push wird ein sogenannter Pull-Request ausgelöst, in dem ein Code-Review durchgeführt und anschließend der Pull-Request bestätigt wird, wenn alles in Ordnung ist. Parallel dazu finden bereits automatisierte Tests statt, die den neuen Code auf mögliche Fehler prüfen. Wenn einer dieser Tests fehlschlägt, wird sofort eine Information dazu verschickt und der Code kann nachbessert werden. Werden alle Tests bestanden, wird der neue Code übernommen. Unabkömmlich ist in dieser Phase ein Build Server wie z.B. Jenkins.

Test

Neben den Testverfahren, die bereits in der Buildphase durchlaufen werden, finden tiefergehende Tests in einer eigenen Umgebung statt, auf die zusätzlich deployed wird. Diese Umgebung wird häufig als „Staging Environment“ bezeichnet. In dieser Umgebung finden neben tiefgehenden, automatisierten Tests auch manuelle Tests statt – dies können z.B. Integrations- und Sicherheitstests sein, um etwaige Schwachstellen in der Applikation aufzudecken. Zusätzlich können auch Nutzerakzeptanztests im Staging Environment durchgeführt werden, bevor die Veröffentlichung erfolgt. Tests können z.B. mit SonarQube oder Sonatype Lifecycle durchgeführt werden.

Release

Nachdem diese umfangreichen und tiefgehenden Testverfahren durchlaufen sind, kann die Veröffentlichung in eine produktive Umgebung vorbereitet werden. An dieser Stelle wird entschieden, welche Änderungen in dem Release enthalten sein sollen. Je nach Reifegrad des Release-Prozesses, kann dies ein manueller oder automatischer Schritt sein. Manche Unternehmen veröffentlichen neue Versionen nach festen Zeitplänen, andere tun dies automatisiert, sobald ein neuer Code erfolgreich durch die Testphase gegangen ist. Es ist möglich, dass festen Personen die Rolle eines Release-Managers zugewiesen wird. Für die Verwaltung von Versionen und Releases können Artefakt-Repository-Management Tools wie Nexus Repository benutzt werden.

Deploy

In dieser Phase findet das tatsächliche Ausrollen des neuen Builds statt. Durch moderne Tools ist dies heutzutage automatisiert und ohne Unterbrechungen des laufenden Betriebs möglich. Hier kann derselbe Code verwendet werden, der bereits für die Ausbringung in die Testumgebung verwendet worden ist – Stichwort: Infrastructure-as-a-Code. Sollte es unerwarteter Weise zu Schwierigkeiten im Deployment kommen, kann ohne Probleme der vorherige Stand der produktiven Umgebung vorübergehende wiederhergestellt werden. Ein automatisiertes Deployment kann z.B. mit Jenkins durchgeführt werden.

Operate

Die Änderungen sind nun live und stehen den Usern zur Verfügung. In dieser Phase spielt vor allem der Teil des Teams eine Rolle, der sich vorrangig mit dem Betrieb – Operations – beschäftigt.

Moderne Tools sorgen automatisiert dafür, dass Lastspitzen effektiv abgefangen werden und jederzeit die benötigten Ressourcen bereitstehen, um die Produktivumgebung effektiv zu betreiben. Zusätzlich hat der Kunde die Möglichkeit, Feedback an das Team zurückzugeben. Nur so können wertvolle Einblicke erlangt werden, wie die Software genutzt wird und was sich die User wünschen. Dies ist einer der größten Erfolgsfaktoren und muss unbedingt sichergestellt werden!

Monitor

Ergänzend zum direkten Feedback der User sollten weitere Daten erhoben werden, die bei der Nutzung anfallen. Dies können z.B. auftretende Fehler, Latenzzeiten, Zugriffszahlen und das individuelle Nutzverhalten der User sein. Die Mischung aus direktem Kundenfeedback und den zusätzlich erhobenen Daten kann dann zurück an die Produkt-Verantwortlichen und Entwicklungsteams fließen, um daraus die nächsten Features abzuleiten. Auf diese Art und Weise wird genau das entwickelt, was sich die User wirklich wünschen und brauchen. 

Continuous… Everything!

Da es sich bei diesen Phasen, wie eingangs erwähnt, um einen fortlaufenden Prozess handelt, treffen Sie im Bereich DevOps häufig auf Schlagwörter wie Continuous Integration, Continuous Delivery und Continuous Deployment, allgemein abgekürzt als CI/CD. Was diese Begriffe genau bedeuten und wie diese mit den oben genannten Phasen zusammenpassen, schauen wir uns nun genauer an.

Continuous Integration

Im Kern bedeutet Continuous Integration, dass Codeänderungen häufig und regelmäßig in ein gemeinsames Repository integrieren werden. Das klingt vielleicht nicht unbedingt revolutionär, bildet aber eine unentbehrliche Grundlage für alle Vorgehensweisen, Prinzipien und Schritte eines DevOps Vorgehens.

Das häufigere Integrieren dieser kleineren Software-Teile sorgt dafür, dass regelmäßig getestet wird, die Komplexität der einzelnen Teile sinkt und Fehler / Kompatibilitätsprobleme leichter und schneller behoben werden können. Dadurch muss weniger Debugging betrieben werden. Außerdem wird die Sichtbarkeit von Änderungen im Team erhöht und eine nachhaltige, solide Grundbasis für alle kommenden Änderungen gelegt.

Automatisierte Tests spielen hier bereits eine große Rolle, damit der manuelle Testaufwand gesenkt wird. Durch die häufigere Integration der Softwareteile werden augenscheinlich mehr Bugs gefunden – diese sind aber deutlich leichter zu beheben, da die Programmbestandteile kleiner und weniger komplex sind.

Am Ende soll durch dieses Vorgehen ein leichter und wiederholbarer Prozess entstehen, der Bugs automatisiert aufdeckt, Kosten einspart und den gesamtem Softwarezyklus effizienter macht.

Continuous Delivery & Continuous Deployment

Wenn diese Herangehensweise auf der Basis von Continuous Integration noch weiter automatisiert und ausgedehnt wird, spricht man von Continuous Delivery – die Software kann also fortwährend aus der Codebasis ausgeliefert, sprich deployed werden.

Wenn der Code alle Testphasen erfolgreich durchläuft (Unit- / Integration- / Systemtests) und im Staging Environment erfolgreich deployed wurde, kann eine manuelle Freigabe, im besten Fall per Knopfdruck, in die produktive Kundenumgebung erfolgen.

Wenn auch der Freigabeprozess zum Deployment auf die produktive Umgebung automatisiert ist, wird von Continuous Deployment gesprochen. Sind hier noch manuelle Schritte notwendig, wird von Continuous Delivery gesprochen.

Continuous Deployment ist damit also das ultimative Ziel der modernen Softwareentwicklung und führt immer über den Weg einer schrittweisen Implementierung und Entwicklung von Continuous Integration und Continuous Delivery.

Continuous Feedback

Das letzte Kernelement kann als ein grundsätzliches Ziel verstanden werden – fortwährendes Feedback vom Markt und Usern einholen. Letztlich ist es das Ziel von DevOps, die Software schneller in die Hände der User zu bringen, um eine direkte Rückmeldung zu erhalten, wie die neuen Features aufgenommen werden.

Dieses Feedback fließt dann wieder zurück in den Entwicklungsprozess und steuert so maßgeblich die weitere Vorgehensweise des Teams. Auf diese Weise entsteht eine effektive Feedback-Schleife, die eine wichtige Orientierung für die Ausrichtung und Gestaltung Ihrer Softwareprodukte liefern kann und sollte.

Als Feedback zählen hierbei nicht nur Kundenstimmen, die beispielsweise über Communities und direkte Rückmeldungen der User erfolgen, sondern auch automatisierte Metriken, die eine moderne DevOps Pipeline für Sie bereitstellt. Wenn Sie beispielsweise ein Update ausliefern und Ihr Monitoring-Tool meldet, dass seit der Auslieferung die CPU- und Speicher-Auslastung des Produktivservers in kritische Bereiche gestiegen ist, ist dies auch ein wichtiges Feedback, das Einfluss auf das weitere Vorgehen Ihres Teams hat.

Eine moderne DevOps-Toolchain unterstützt all diese Konzepte, Phasen und Vorgehensweisen mit geeigneten Werkzeugen, die Ihnen die Umsetzung der Softwareentwicklung nach dem DevOps-Prinzip erheblich erleichtern können. Wir haben dafür das Cloudogu EcoSystem entwickelt - Damit müssen Sie keine lange Recherche oder tagelange Konfigurationsarbeit betreiben. Mit unserem EcoSystem setzen Sie ihre eigene CI/CD-Toolchain in nur 30 Minuten auf. Sprechen Sie uns an!