DevOps-Technologie: Continuous Delivery

Continuous Delivery ermöglicht die schnelle, sichere und nachhaltige Bekanntgabe von Änderungen aller Art. Teams, die Continuous Delivery geschickt nutzen, können Software-Releases und Änderungen in der Produktion jederzeit – auch während der Geschäftszeiten – und mit geringem Risiko vornehmen, ohne die Nutzer zu beeinträchtigen.

Sie können die Grundsätze und Vorgehensweisen der Continuous Delivery auf jeden beliebigen Softwarekontext anwenden. Dazu zählen:

  • Aktualisierung von Diensten in komplexen verteilten Systemen
  • Aktualisierungen von Mainframe-Software
  • Änderungen an der Infrastrukturkonfiguration
  • Änderungen am Datenbankschema
  • Automatische Firmware-Aktualisierungen
  • Releases neuer Versionen einer mobilen App

Wenn Ihr Team mit Continuous Delivery arbeitet, können Sie folgende Fragen mit "Ja" beantworten:

  • Ist unsere Software über ihren gesamten Lebenszyklus in einem bereitstellungstauglichen Zustand?
  • Hat die Bereitstellungstauglichkeit der Software für uns Vorrang vor der Arbeit an neuen Features?
  • Steht in Bezug auf die Qualität und Bereitstellungstauglichkeit des Systems, an dem wir gerade arbeiten, jedem im Team schnelles Feedback zur Verfügung?
  • Hat für uns die Problemlösung oberste Priorität, wenn wir Feedback erhalten, dass ein System nicht bereitgestellt werden kann (z. B. nach fehlgeschlagenen Builds oder Tests)?
  • Kann das System bei Bedarf jederzeit für die Produktion oder für Endnutzer bereitgestellt werden?

Continuous Delivery wird häufig mit kontinuierlichen Bereitstellung verbunden, allerdings sind dies separate Verfahren. Kontinuierliche Bereitstellung bedeutet, dass Teams versuchen, jede Codeänderung so schnell wie möglich in die Produktion zu übernehmen. Continuous Delivery funktioniert gut für Webdienste, kann jedoch nicht auf Software, wie Firmware oder mobile Apps, angewendet werden. Continuous Delivery wird auf alle Arten von Software, einschließlich Firmware- und Mainframe-Systemen, sowie in stark regulierten Umgebungen angewendet. Sie können und sollten beginnen, mit Continuous Delivery zu arbeiten, auch wenn Sie nicht die Absicht haben, kontinuierliche Bereitstellung zu nutzen.

Continuous Delivery und die kontinuierliche Bereitstellung werden fälschlicherweise als riskant und ungeeignet für regulierte oder sicherheitsrelevante Domains angesehen. Das Ziel der Continuous Delivery besteht jedoch darin, Softwarerisiken zu reduzieren. Die DORA-Studie hat deutlich gezeigt, dass leistungsstarke Unternehmen damit eine höhere Zuverlässigkeit und Verfügbarkeit erzielen. Die technischen Aspekte für die Continuous Delivery, wie kontinuierliche Tests, Shift Left für Sicherheit sowie umfassende Tests und Beobachtbarkeit, sind in streng regulierten und sicherheitsrelevanten Domains noch wichtiger. Bei streng regulierten Domains, wie von Finanzdienstleistern und Regierungsbehörden, wird Continuous Delivery bereits vielfach erfolgreich genutzt.

Continuous Delivery ist für alle Arten von Software möglich, aber nicht einfach in der Umsetzung. Trotzdem bietet sie große Vorteile. DevOps Research and Assessment (DORA) zufolge bietet eine gute Continuous Delivery folgende Vorteile:

  • Sie verbessert die Leistung der Softwarebereitstellung in Bezug auf die vier zentralen Messwerte und die Verfügbarkeit.
  • Sie verkürzt den Anteil der Zeit, die Teams für Nachbesserungen oder ungeplante Arbeit benötigen (siehe State of DevOps-Bericht 2016, Seiten 25–26, und State of DevOps-Bericht 2018, Seiten 27–29).
  • Beim Personal treten weniger Erschöpfungserscheinungen auf (körperliche, geistige oder emotionale Erschöpfung) aufgrund von Überarbeitung oder Stress auf, die Zufriedenheit am Arbeitsplatz steigt und dies fördert eine positive Unternehmenskultur.
  • Sie reduziert Probleme bei der Bereitstellung, die deutlich machen, welche Bereitstellungen disruptiv und nicht einfach umzusetzen sind. Außerdem haben Entwickler und technische Mitarbeiter weniger Angst, wenn sie Code in die Produktion übernehmen.
  • Sie nimmt Einfluss auf die Kultur, weil sie die psychologische Sicherheit erhöht und damit eine zielorientierte Unternehmenskultur fördert.

Das folgende Diagramm zeigt, wie sich einige technische Verfahren auf die Continuous Delivery auswirken und so dazu beitragen, die oben genannten Ergebnisse zu erzielen:

So wirken sich technische Verfahren positiv auf andere Bereiche aus

Continuous Delivery ist zwar nur einer der Aspekte, die zu den oben genannten Ergebnissen beitragen, aber ein sehr wichtiger. Im DORA-Forschungsprogramm werden weitere kulturelle und organisatorische Fähigkeiten beschrieben, die ebenfalls dazu beitragen. Sie können Continuous Delivery erreichen, wenn Sie die in diesem Dokument beschriebenen technischen Verfahren implementieren.

Continuous Delivery implementieren

Der DORA-Studie zufolge kann Continuous Delivery mithilfe der folgenden technische Ressourcen erreicht werden. Aber auch transformationale Führung innerhalb der Organisation fördert die Implementierung vieler dieser technischen Funktionen.

Mit den folgenden Best Practices für Continuous Delivery ermöglichen Sie Ihrem Team, einen höheren Arbeitsdurchsatz zu erzielen und gleichzeitig Releases mit geringerem Risiko zu veröffentlichen.

  • Testautomatisierung: Verwendung umfangreicher automatischer Testsuiten, die hauptsächlich von Entwicklern erstellt und gewartet werden. Effiziente Testsuiten liefern zuverlässige Ergebnisse, d. h., es werden reale Fehler gefunden und Code besteht diese Tests nur, wenn er für das Release bereit ist.
  • Automatisierte Bereitstellung: Umfang, in dem Bereitstellungen vollständig automatisiert sind und keine manuellen Eingriffe erfordern.
  • Trunk-basierte Entwicklung: Entwicklung mit weniger als drei aktiven Zweigen in einem Code-Repository. Zweige und Forks haben eine sehr kurze Lebensdauer (z. B. weniger als einen Tag), bevor sie in der Mainline zusammengeführt werden. Außerdem haben Anwendungsteams selten oder nie Codesperren, während der niemand Code einchecken oder aufgrund von Problemen bei der Zusammenführung Code-Fixierungen oder Stabilisierungsphasen niemand Pull-Anfragen senden kann.
  • Shift Left für Sicherheit: Einbindung der Sicherheitsaspekte in die Design- und Testphasen des Softwareentwicklungsprozesses. Dieser Prozess umfasst Prüfungen der Anwendungssicherheit unter Einbeziehung des Teams für Informationssicherheit in das Design und die Demonstration der Anwendungen, die Verwendung von vorab genehmigten Sicherheitsbibliotheken und -paketen sowie das Testen von Sicherheitsfunktionen als Teil der automatisierten Testsuite.
  • Lose gekoppelte Architektur: Architektur, mit der Teams ihre Anwendungen bei Bedarf testen und bereitstellen können, ohne dass andere Dienste orchestriert werden müssen. Durch eine lose gekoppelte Architektur können Ihre Teams unabhängig von den anderen Teams für Support und Dienste arbeiten. Dies beschleunigt ihre Arbeit, sodass für das Unternehmen ein größerer Mehrwert geschaffen wird.
  • Selbstständige Wahl der Tools durch die Teams: Die Teams können selbst entscheiden, welche Tools sie für eine optimale Continuous Delivery verwenden möchten. Denn niemand weiß besser als die Praktiker selbst, was sie für effizientes Arbeiten benötigen
  • Continuous Integration (CI): Dies ist eine Entwicklungsmethode, bei der Code regelmäßig eingecheckt wird. Jeder Check-in löst eine Reihe von kurzen Tests aus, um Regressionen zu erkennen und sofort zu beheben. Im Rahmen des CI-Prozesses werden kanonische Builds und Pakete erstellt, die letztendlich bereitgestellt und veröffentlicht werden.
  • Kontinuierliche Tests: Hierbei werden Tests über den gesamten Lebenszyklus der Softwarebereitstellung ausgeführt und nicht als separate Phase nach Abschluss der Entwicklung. Bei kontinuierlichen Tests arbeiten die Entwickler und Tester zusammen. Leistungsstarke Unternehmen entwickeln lösungsorientiert und erhalten Test-Feedback in weniger als zehn Minuten. Außerdem prüfen und optimieren sie auch ihre Testsuiten fortlaufend, beispielsweise, um Fehler zu finden und die Komplexität in Grenzen zu halten.
  • Versionsverwaltung: Nutzung eines Versionsverwaltungssystems wie Git oder Subversion für alle Artefakte der Produktion, einschließlich Anwendungscode, Anwendungskonfigurationen, Systemkonfigurationen und Skripts zur Automatisierung der Erstellung und Konfiguration von Umgebungen.
  • Testdatenverwaltung: Voraussetzungen für eine effektive Vorgehensweise sind unter anderem die Verfügbarkeit ausreichender Datenmengen, um Testsuite auszuführen, die Möglichkeit, nach Bedarf erforderliche Daten abzurufen, und dass die Anzahl der ausführbaren Tests nicht durch Daten begrenzt sind. Wir empfehlen, dass Ihre Teams möglichst wenig Testdaten brauchen, um automatisierte Tests durchzuführen.
  • Umfassendes Monitoring und Beobachtbarkeit: Dies hilft den Teams, den Status ihrer Systeme besser zu verstehen. Effektive Lösungen ermöglichen es den Teams, vordefinierte Messwerte zu überwachen, einschließlich des Systemstatus, wie er von Nutzern wahrgenommen wird. Außerdem können Entwickler so Systeme interaktiv debuggen sowie Attribute und Muster im Zeitverlauf untersuchen.
  • Proaktive Benachrichtigungen: Monitoring des Systemzustands, damit Teams Probleme frühzeitig erkennen und beheben können.
  • Änderungsmanagement für Datenbanken: Datenbankänderungen müssen die Arbeit der Teams nicht ausbremsen, wenn einige wichtige Praktiken befolgt werden. Dazu zählen beispielsweise das Speichern von Datenbankänderungen als Skripts in der Versionsverwaltung und das Verwalten dieser Änderungen auf die gleiche Weise, wie bei Produktionsanwendungen. Auf diese Weise sind Datenbankänderungen für jeden im Softwarebereitstellungszyklus (einschließlich Entwicklern) sichtbar und alle Beteiligten können kommunizieren, wenn Änderungen an der Anwendung auch Datenbankänderungen erfordern.
  • Verwaltbarkeit von Codes: Systeme und Tools, mit denen Entwickler von anderen Personen verwalteten Code ändern, Beispiele in der Codebasis finden, Code anderer Personen wiederverwenden sowie Code hinzufügen, aktualisieren oder zu neuen Versionen von Abhängigkeiten migrieren können, ohne den ursprünglichen Code zu verändern.

Continuous Delivery wird häufig mit Continuous Integration kombiniert und mit CI/CD abgekürzt. Studien zeigen, dass die Continuous Integration nur ein Bestandteil der Implementierung von Continuous Delivery ist. Für zuverlässige, risikoarme Releases ist eine enge Zusammenarbeit zwischen allen an der Softwarebereitstellung Beteiligten und nicht nur der Softwareentwickler untereinander erforderlich. Außerdem muss Ihr Team dafür neue Arbeitsweisen erschließen und neue Kompetenzen erwerben.

Häufige Stolperfallen bei der Implementierung von Continuous Delivery

Einige Organisationen glauben fälschlicherweise, dass Continuous Delivery darin besteht, ihren vorhandenen Prozess der kontinuierlichen Bereitstellung einfach öfter zu wiederholen. Die Implementierung der technischen Funktionen, die Continuous Delivery unterstützen, erfordert jedoch in der Regel erhebliche Prozess- und Architekturänderungen. Wenn Sie ohne Verbesserung der Prozesse und Architektur einfach öfter bereitstellen, erreichen Sie damit wahrscheinlich nicht mehr, als höhere Fehlerraten und erschöpfte Teams.

Viele Beschreibungen der Continuous Delivery konzentrieren sich auf die Tools und Muster, wie die Bereitstellungspipeline, die Änderungen von der Versionsverwaltung bis zur Produktion vornimmt. Wenn Sie jedoch moderne Tools nutzen, ohne die hier beschriebenen, erforderlichen technischen Verfahren und Prozessänderungen zu implementieren, werden Sie nicht die gewünschten Ergebnisse erzielen.

Das folgende Diagramm zeigt die J-Kurve, nach der laut DORA-Studie Transformationsprogramme typischerweise ablaufen. Wenn Ihr Team am Anfang dieser Kurve steht, muss es zuerst die Prozesse umgestalten und vereinfachen, die Architektur optimieren, Fähigkeiten und Kompetenzen entwickeln sowie Automatisierung und Tools implementieren.

J-Kurve: typischer Verlauf der Transformation. Quelle: Bericht "State of DevOps 2018"

Im Diagramm sind die folgenden Phasen beschriftet:

  • Am Anfang der Kurve beginnen Teams mit der Transformation und identifizieren schnelle Erfolge.
  • Bei einer ersten Verbesserung können Unternehmen mit geringer Leistung durch Automatisierung zu durchschnittlicher Leistung gelangen.
  • Bei Effizienzverlust (unterer Bereich der J-Kurve) erhöht die Automatisierung die Testanforderungen, die manuell angepasst werden müssen. Ein großer Anteil technischer Altlasten behindert den Fortschritt.
  • Während sich Teams entlang der Kurve nach oben arbeiten, führen technische Altlasten und zunehmende Komplexität dazu, dass immer mehr manuelle Kontrollen und Prozessebenen in Bezug auf Änderungen hinzukommen, was die Arbeit verlangsamt.
  • Oben in der Kurve führt kompromisslose Optimierungsarbeit zu Spitzenleistung. Die Leistungsstärksten nutzen Fachwissen und lernen von ihren Umgebungen, um die Produktivität zu steigern.

Eine gute Möglichkeit, die Auswirkungen der J-Kurve abzuschwächen, bietet eine Wertstromanalyse (Value Stream Mapping, VSM). Mithilfe dieser Analyse können Sie mögliche Engpässe identifizieren und deren Auswirkungen prognostizieren. Bei einer VSM betrachten Sie jeweils eine einzelne Änderung im Prozess von der Versionsverwaltung bis zur Produktion.

  1. Berücksichtigen Sie die verschiedenen Prozesse, die jede Änderung durchläuft. Dazu gehören automatische und manuelle Tests, Sicherheitsprüfungen, das Änderungsmanagement und die Freigabe für die Produktion.
  2. Messen Sie die Gesamtzeit, die nach einer Änderung von der Versionsverwaltung bis zum Release verstreicht. Messen Sie für jeden Prozess Folgendes:
    • Die tatsächlich verstrichene Zeit und die Wertschöpfungszeit (effektive Arbeitszeit) vom Anfang bis zum Ende des Prozesses.
    • Prozentualer Anteil am Zeitaufwand, der entsteht, weil eine beim ersten Mal nicht korrekt ausgeführte Aufgabe zurückgesendet werden muss. Dieser Messwert wird als %C/A (Percentage Complete and Accurate) bezeichnet.

Die Wertstromanalyse hilft Ihnen, Ineffizienzen in Ihrem Prozess aufzudecken. Erstellen Sie im Team ein Diagramm, das darstellt, wie der Wertstrom in sechs Monaten aussehen soll. Legen Sie außerdem eine feste Teamkapazität fest, mit der dieser Status erarbeitet werden soll. Identifizieren und beseitigen Sie Hindernisse, wie Prozesse, die im Verhältnis zur Wertschöpfungszeit zu lange dauern oder eine schlechte %C/A haben.

Die Implementierung einer Bereitstellungspipeline erfordert in der Regel eine umfangreiche Neugestaltung des Prozesses und der Architektur. Da die Bereitstellungspipeline vom Check-in bis zum Release reicht, sind hier mehrere Teams beteiligt. Daher ist es wichtig, dass Mitarbeiter aus allen Teams eine Wertstromanalyse machen und sich dann auf eine gemeinsame Toolchain sowie entsprechende Prozesse einigen (z. B. für die Bereitstellung in den Test- und Produktionsumgebungen), um auf den gewünschten Status hinzuarbeiten.

Die Implementierung von Continuous Delivery ist ein Prozess kontinuierlicher, täglicher Optimierungsarbeit, die auf die gewünschten Ergebnisse abzielt. Tools und Muster sind wertvoll, aber nur, wenn sie im Dienst dieser Optimierungsarbeit stehen.

Continuous Delivery messen

Continuous Delivery soll gewährleisten, dass Releases während der normalen Geschäftszeiten und mit einem geringen Risiko herausgegeben werden können. Ziel ist, dass niemand außerhalb der normalen Geschäftszeiten an Bereitstellungen oder Releases arbeitet. Daher ist es wichtig, diesen Aspekt bei der Messung zu berücksichtigen.

Wie effizient Ihre Continuous Delivery ist, spiegelt sich in den Ergebnissen wider, die damit erzielt werden. Mit dem DORA-DevOps-Schnelltest können Sie ermitteln, wie sich die wichtigsten Messwerte der Continuous Delivery entwickeln:

  • Kurze Vorlaufzeiten sowohl für reguläre als auch für Notfalländerungen mit dem Ziel, auch Notfalländerungen im Rahmen des regulären Prozesses vorzunehmen
  • Geringe Änderungsausfallraten
  • Kurzfristige Wiederherstellung von Diensten bei Ausfällen oder Dienststörungen
  • Release-Häufigkeit, die gewährleistet, dass Features mit hoher Priorität und Fehlerkorrekturen zeitnah veröffentlicht werden

Wie schon zu Beginn dieses Dokuments erläutert, sollte die Implementierung der Continuous Delivery auch zu weniger Nachbesserungen und Bereitstellungsproblemen sowie zu einem geringeren Zeitaufwand für korrigierende und ungeplante Arbeiten führen.

Nächste Schritte