Was ist kontinuierliche Bereitstellung?

Früher musste eine Software, bevor sie für den Endbenutzer freigegeben werden konnte, langwierige Zyklen der Entwicklung, Prüfung und Überarbeitung durchlaufen. Diese Wasserfallmethode, bei der ganze Produkte im Voraus entwickelt, getestet und dann bereitgestellt werden, war extrem zeitaufwändig, verursachte schleppende Bereitstellungszyklen und beeinträchtigte die Experience der Benutzer.

Die kontinuierliche Bereitstellung ist eine Kernkomponente von DevOps und gehört in den Gesamtkontext von CI/CD. Entstanden ist die kontinuierliche Bereitstellung im Rahmen der Revolution der agilen Software. Anstatt komplette Pakete auf einmal zu erstellen, werden bei der kontinuierlichen Bereitstellung alle Aspekte der Erstellung von Code, der in die Produktion gehen könnte, berücksichtigt, während fortgeschrittene Automatisierungslösungen für sich wiederholende Aufgaben wie Tests eingesetzt werden. Unter bestimmten Umständen kann der Code direkt in die Produktion gehen – dies wird auch als kontinuierliche Bereitstellung bezeichnet.

Für Unternehmen und Softwareanbieter ergeben sich daraus eine Reihe wichtiger Vorteile:

Wenn Entwickler umfangreiche Bereitstellungen veröffentlichen, kann eine Menge schief gehen. Die kontinuierliche Bereitstellung verringert das Risiko der Bereitstellung, indem sie den Schwerpunkt auf kleinere Changes legt, die leichter zu überprüfen und zu beheben sind und weniger Zeit zur Korrektur benötigen, falls sie nicht wie erwartet funktionieren.

Die kontinuierliche Bereitstellung ermöglicht es den Verantwortlichen von Anwendungen und Projekten, den Fortschritt zu verfolgen und zu entscheiden, wann und wie die Bereitstellung in Produktions- oder Testumgebungen stattfinden soll, anstatt lediglich darauf zu warten, dass die Entwickler entscheiden, wann die Arbeit abgeschlossen ist. In einigen Fällen kann es sinnvoll sein, die während des gesamten Lebenszyklus der kontinuierlichen Bereitstellung gesammelten Informationen im Rahmen einer Lösung für das Wertstrommanagement zu nutzen, um die relativen Fähigkeiten der Teams zu verstehen und Engpässe zu erkennen und zu beseitigen.

Wenn die Bereitstellung von Software in vorher festgelegten Entwicklungsphasen erfolgt, können einzelne Phasen viel Zeit in Anspruch nehmen. Die kontinuierliche Bereitstellung zwingt Teams dazu, Tests und Fehlerbehebung in andere tägliche Prozesse zu integrieren und sich auf die Automatisierung bei der Erstellung, Bereitstellung usw. zu verlassen, um die Last zu verteilen. So lässt sich die Anzahl der Entwicklungsphasen verringern, es gibt weniger redundante Arbeit und die Durchlaufzeiten sind kürzer. Typisch für die kontinuierliche Bereitstellung ist, dass die Software jederzeit freigegeben werden kann – eine deutliche Verbesserung gegenüber den langen Bereitstellungszeiten der herkömmlichen Softwareentwicklung.

Entwickler, die viel Zeit in die Entwicklung einer Anwendung investieren, um dann bei der Veröffentlichung festzustellen, dass sie ineffektiv ist oder nicht gut ankommt, stehen wieder am Anfang und können ihren Aufwand nur schwer rechtfertigen. Durch kürzere, häufigere Veröffentlichungen kommen Probleme beim Testen und andere Schwierigkeiten schneller ans Licht und die Benutzer der Anwendung können frühzeitig und häufig Feedback geben, sodass die Entwickler bei Bedarf entsprechende Korrekturen vornehmen können.

Mit zuverlässigem Feedback während des gesamten Lebenszyklus können Entwickler ihre Produkte verbessern und straffen, indem sie Funktionen und Ideen testen und auf alles verzichten, was unnötig oder ineffektiv ist oder sich negativ auf die Experience der Benutzer auswirkt.

Die kontinuierliche Bereitstellung setzt auf Automatisierung, um viele der Fixkosten zu eliminieren, die die Softwareentwicklung traditionell belastet haben. Daraus ergeben sich geringere Investitionskosten im Vorfeld und während des gesamten Entwicklungszyklus und eine höhere Rendite bei den verbleibenden Kosten.

Entwicklungsmarathons und bevorstehende Projektabgabetermine zermürben die Entwicklungsteams oft. Umgekehrt lassen sich kleinere Korrekturen und Veröffentlichungen leichter und in Verbindung mit anderen Aufgaben verwalten. Die kontinuierliche Bereitstellung trägt nicht nur zu einem weniger stressigen Arbeitsumfeld bei und beugt Burnout vor, sondern ermöglicht es den Entwicklern auch, direkter mit den Benutzern zu interagieren und den Nutzen ihrer Arbeit für die Kunden besser nachvollziehen zu können.

Oberflächlich betrachtet, sind sich kontinuierliche Bereitstellung und kontinuierliches Deployment sehr ähnlich. Aber auch wenn beide zur agilen Softwareentwicklung gehören, gibt es feine Unterschiede zwischen den zwei Spielarten, die zu berücksichtigen sind.

Wie vorstehend beschrieben, automatisiert die kontinuierliche Bereitstellung viele der Prozesse, die mit der Softwareentwicklung verbunden sind. Teams können so inkrementelle, kontinuierliche Changes an Produkten vornehmen. Was bei der kontinuierlichen Bereitstellung jedoch nicht automatisiert wird, ist die letzte Phase: die Genehmigung der Bereitstellung für die Produktion. Änderungen, die vorgenommen und in Testumgebungen übertragen wurden, werden in der Regel manuell überprüft und genehmigt, bevor sie in die Bereitstellung übergehen.

Das kontinuierliche Deployment geht noch einen Schritt weiter, indem Updates entweder nach einem vordefinierten Zeitplan automatisch bereitgestellt werden oder sobald der Code im Rahmen des Prozesses der kontinuierlichen Bereitstellung übergeben wird. Wenn für den Code kein Bereitstellungsfenster erforderlich ist, erhalten die Entwickler durch die zuverlässige Automatisierung der Change Governance (sofern verwendet) im Wesentlichen direkten Zugriff auf die Produktion und können sicherstellen, dass die Aktualisierungen regelmäßig bereitgestellt werden, ohne dass sie die Bereitstellung selbst durchführen müssen. Dadurch erhalten Unternehmen mehr Kapazität, um mehr Bereitstellungen zu einem bestimmten Zeitpunkt zu veröffentlichen, es wird sogar ein großer Teil des Aufwands für größere Releases vermieden. Für die meisten Unternehmen kommt kontinuierliches Deployment aufgrund von strengen Governance-Anforderungen nicht in Frage, etwa durch Branchenvorschriften. Die Implementierung von kontinuierlichem Deployment hängt in solchen Unternehmen weitgehend von der Fähigkeit ab, die bisher manuell durchgeführten Genehmigungen zu automatisieren, z. B. im Rahmen eines formellen Change-Management-Prozesses.

Das Gesamtkonzept der kontinuierlichen Bereitstellung ist leicht zu erfassen: Zeitintensive Entwicklungsprozesse werden in kleine, automatisierte Aufgaben und Veröffentlichungen aufgeteilt. Das Konzept zu verstehen und zu wissen, wie man die Methodik umsetzt, sind jedoch zwei paar Schuhe. Die folgenden Punkte sind wichtige Voraussetzungen für die Umstellung auf kontinuierliche Softwarebereitstellung:

Der bereits erwähnte Wasserfall-Ansatz für die Softwareentwicklung ist in den Köpfen und Prozessen der Entwicklungsteams möglicherweise noch tief verwurzelt. Daher erfordert der Kulturwandel hin zu DevOps und agiler Entwicklung eine umfassende Planung und gründliche Schulung. Wenn sich die Entwicklungsteams nicht entsprechend einbringen, wird die kontinuierliche Bereitstellung wahrscheinlich nicht erfolgreich sein.

Die Umstellung der Denkweise hin zu DevOps muss über die Grenzen der Softwareentwicklung hinaus reichen. Schnelle Feedbackschleifen und eine effektive Entscheidungsfindung erfordern eine effiziente Zusammenarbeit und Koordination mit den Führungskräften, damit alle die richtigen Prozesse kennen und beherzigen.

Schnelle Durchlaufzeiten und problemlose Software-Releases nützen Unternehmen nicht viel, wenn die Endprodukte den Sicherheits- oder Compliance-Anforderungen nicht standhalten können. Glücklicherweise lassen sich viele der Automatisierungs-Tools, die im Rahmen der kontinuierlichen Bereitstellung verwendet werden, auch dazu einsetzen, das mit der Bereitstellung verbundene Sicherheitsrisiko zu minimieren. Automatisierte Code-Scanning-Tools mit Richtlinien, die von spezialisierten Sicherheitsteams festgelegt werden, sind Teil der Pipeline. Wenn automatisiertes Change-Management implementiert ist, werden die erfolgreichen Durchläufe dieser Scans zu einem Teil der Informationen, die zur automatischen Erstellung und Genehmigung von Change-Anforderungen verwendet werden.