Da DevOps-Methoden den Softwarebereitstellungszyklus erheblich schneller und zuverlässiger machen können, ist Release Management in diesem Zusammenhang vielleicht eine eher abschreckende Vorstellung. Doch die durch DevOps verbesserte Transparenz und Zusammenarbeit können sich durchaus positiv auf den Release-Management-Prozess auswirken. Das allgemeine Konzept von Release Management ist bei ITIL (IT Infrastructure Library) und DevOps zwar im Wesentlichen dasselbe, doch der Prozess unterscheidet sich in einigen Aspekten.
Zum einen ist ITIL ein spezifisches Framework für IT-Operations-Prozesse, während DevOps sich ständig selbst verbessert. Zum anderen gibt es mehr als einen Weg, DevOps umzusetzen; bei ITIL dagegen handelt es sich um eine Reihe von Anweisungen, denen man generell folgen sollte. Das Problem bei ITIL ist, dass jedes Team anders arbeitet. Es gibt also keinen allgemeingültigen Ansatz für IT Operations und Release Management.
DevOps-orientiertes Release Management ist die Zukunft von Softwareentwicklung und IT Operations. Das ist der Grund, warum wir diesen Beitrag geschrieben haben – er soll euch ein paar Best Practices und Tools für das DevOps Release Management zeigen, mit denen euer Team zuverlässige Software abliefert und dabei kurz getaktete Bereitstellungspläne einhalten kann.
Was bedeutet Release Management?
Unter Release Management versteht man bei Softwareentwicklung und IT Operations ein System zur Verwaltung des gesamten Softwarebereitstellungszyklus – von der Planung über die Erstellung bis hin zu Testing und Bereitstellung. Dieser allgemeine Prozess gilt sowohl für ITIL als auch DevOps. DevOps fördert jedoch mehr die Zusammenarbeit und Transparenz innerhalb des Bereitstellungsprozesses. Dies verkürzt die Feedback-Schleifen und trägt zu einem einfacheren, schnelleren Release Management bei.
Sehen wir uns die Release-Management-Prozesse für ITIL- und DevOps-Teams an.
ITIL Release Management
Der Release-Management-Prozess mit ITIL besteht darin, neue Bereitstellungen zu planen und ihre Integrität zu wahren, und zwar durchgängig. Bei ITIL erhält das IT-Operations-Team den Code aus der Softwareentwicklung und entscheidet dann, wann und wie der Service bereitgestellt wird, ohne dass man dazu vorhandene Services unterbrechen muss.
DevOps Release Management
Auch beim Release Management mit DevOps geht es darum, den Softwareentwicklungs- und Bereitstellungsprozess zu planen, zu terminieren und zu steuern. Bei DevOps arbeiten jedoch sowohl Entwicklung als auch IT Operations von Anfang bis Ende zusammen – dies ermöglicht weniger und kürzere Feedback-Schleifen und schnellere Releases.
DevOps-Teams teilen sich die Zuständigkeit für die Services, die sie bereitstellen, tragen Verantwortung für ihren Code und übernehmen Bereitschaftsaufgaben. Da IT-Fachleute und die Softwareentwicklung in den gesamten Bereitstellungslebenszyklus involviert sind, werden Incidents schneller erkannt und behoben, und zwar sowohl im Verlauf des Release-Prozesses als auch danach.
Sehen wir uns nun einige DevOps-Prinzipien darauf hin an, wie sie sich auf bewährte Release-Management-Verfahren anwenden lassen.
Best Practices für das DevOps Release Management
Erfolgskriterien definieren
Wie weiß man, wann ein Produkt wirklich bereit zur Auslieferung ist? Für Zuverlässigkeit sorgen klare Abnahmeanforderungen sowohl beim Release als auch beim Testing. Die Kriterien eines erfolgreichen Releases dürfen natürlich nicht rein subjektiv sein. Andernfalls könnt ihr nicht aus euren Fehlern lernen und den Release-Management-Prozess immer wieder überarbeiten, bis ihr herausfindet, was am besten funktioniert. Produktverantwortliche, Qualitätsmanager und Release Manager müssen die zentralen Release-Metriken definieren und sich auf Abnahmekriterien einigen, wenn sie ein neues Produkt angehen.
Möglichst geringe Auswirkungen auf die Benutzer
Jedes gute Release Management arbeitet natürlich ständig daran, die Downtime und die Auswirkungen auf die Kunden minimal zu halten. Proaktives Testing, aktives Monitoring und kollaborative Benachrichtigungen in Echtzeit können euch helfen, Probleme bei einem Release festzustellen – und zwar oft noch bevor es die Kunden bemerken. Wenn dann auch noch ein gemeinsamer Incident Response-Plan besteht, kann das Team Incidents schnell beheben und seinen Weg zu einem erfolgreichen Release fortsetzen.
Die Staging-Umgebung optimal nutzen
Es trägt zur Qualität eurer Releases bei, wenn ihr eure Staging-Umgebung kontinuierlich wartet und stets dafür sorgt, dass sie der Produktionsumgebung möglichst ähnlich ist. Alle, von den Produktverantwortlichen bis hin zur Qualitätssicherung, sollten das Staging eingehend prüfen und testen, um mögliche Probleme bei neuen Bereitstellungen aufzudecken. Wenn eure Staging-Umgebung nahezu identisch mit der Produktionsumgebung ist, könnt ihr Probleme leicht schon in der Staging-Umgebung finden, noch bevor ihr den Code in die Produktionsumgebung gebt. Eine gut konzipierte Staging-Umgebung hält die Auswirkungen auf die Kunden minimal und trägt dazu bei, dass eure Releases die Abnahmekriterien eher erfüllen.
CI/CD und Qualitätssicherung optimieren
Der Shift-Left-Ansatz, bei dem bestimmte Aufgaben in frühere Phasen eines Prozesses verlegt werden, ist typisch für DevOps. Durch die Verlagerung von Qualitätssicherung, Automatisierung und Testing in frühere Phasen des Entwicklungslebenszyklus kann das DevOps-Team potenzielle Probleme schneller erkennen. So wird weniger Zeit in Feedback-Schleifen verbracht, und die Delivery Pipeline kann weiterlaufen. Je besser ihr das Testing in die Entwicklungsworkflows integriert, desto leichter lässt sich eine konsistente CI/CD-Pipeline unterhalten.
Die Vorteile der Automatisierung nutzen
Die DevOps-Regel Nummer 1 lautet: Automatisiere alles, was die Effizienz deiner Leute, Prozesse und Technologien verbessern kann. Ob bei Softwareentwicklung, Qualitätssicherung oder IT Operations – nutzt die Möglichkeiten der Automatisierung, um menschliches Versagen zu reduzieren und den Leuten alltägliche Abläufe zu erleichtern! Wenn euer Team mehr Zeit für strategische Überlegungen hat und weniger Zeit in monotone Alltagsaufgaben investieren muss, dann könnt ihr euren Kunden auch konsistent zuverlässige Services liefern.
Möglichst viele unveränderliche Objekte verwenden
In Programmierwelten bedeutet „unveränderlich“, dass der Zustand eines Objekts nicht mehr geändert werden kann, sobald es einmal erstellt ist. Die Programmierung mit unveränderlichen Objekten erzwingt, dass die Teams keine bestehenden Konfigurationen ändern, sondern völlig neue bereitstellen. So werden Fehler vermieden, die beim Ändern aktueller Konfigurationen entstehen könnten. Dies wiederum macht die Releases zuverlässiger und steigert die Zufriedenheit der Beschäftigten und vor allem der Kunden.
DevOps Release Management dreht sich um Menschen
DevOps-Prozesse ergeben von Natur aus eine bessere Release-Management-Struktur, weil sie zu Best Practices bei Zusammenarbeit und Testing im gesamten Bereitstellungslebenszyklus führen. Viele legen den Fokus auf Automatisierung und sehen darin den größten Wert von DevOps. Doch sollte Automatisierung immer darauf ausgelegt sein, die Effizienz der Menschen zu verbessern. Wenn die Beschäftigten weniger menschliche Fehler machen und für operative Effizienz sorgen, dann stellen sie naturgemäß schnell zuverlässige Service-Releases bereit.
Diese Best Practices fürs DevOps Release Management sind nur der Anfang. Wenn Technologien sich weiterentwickeln und das Know-how der Leute wächst, dann müssen sich auch die Release-Management-Prozesse verändern. Die ständige Weiterentwicklung von Menschen, Prozessen und Technologien ist unerlässlich für eine erfolgreiche Release-Management-Struktur mit DevOps.
Splunk Observability Cloud bietet DevOps-Teams die Tools für End-to-End-Monitoring und Benachrichtigungen, die sie für die erfolgreiche Arbeit benötigen. Testet Splunk 14 Tage lang kostenlos und seht selbst, wie wir eurem Team zum Erfolg verhelfen können!
Was ist Splunk?
*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier.
