Was ist Continuous Deployment (CD)?

Wenn Ihre Integrations- und Deployment-Prozesse vollständig manuell ablaufen, mit Code-Freezes, einer Alle-Mann-auf-Deck-Teststrategie und einem unternehmensweiten bangen Luftanhalten am Release-Tag, können stündliche, ereignislose Deployments wie ein Hirngespinst erscheinen.

Die Realität ist jedoch, dass eine ganze Reihe von Unternehmen auf diese Methode setzen – angefangen von großen Namen wie Netflix, Etsy und Amazon bis hin zu Kleinunternehmen, die versuchen, mit dem Markt Schritt zu halten. Durch die Einführung des Continuous-Deployment-Systems konnten diese Unternehmen ihre Release-Zyklen von Wochen oder sogar Monaten auf Stunden verkürzen. In immer mehr Branchen wird es zunehmend wichtig, neue Funktionen zügig bereitzustellen und schnell auf Feedback zu reagieren.

Als Erweiterung von Continuous Integration und Continuous Delivery setzt Continuous Deployment einen vollautomatischen Test- und Build-Deployment-Prozess voraus, damit die Geschwindigkeit nicht auf Kosten der Qualität geht. Die effektive Implementierung von Continuous Deployment erfordert jedoch mehr als diese soliden Grundlagen.

Eine Schlüsselfrage bei der Planung Ihres Continuous-Deployment-Systems ist die Art und Weise, wie Ihre Änderungen in die Produktion übernommen werden sollen. Statt Server offline zu schalten, können Sie zum Beispiel „Rolling Updates“ im laufenden Betrieb durchführen, um häufige Unterbrechungen von Onlinediensten zu vermeiden. Außerdem können Sie den Rollout als Erweiterung Ihres automatisierten Testprozesses realisieren.

Bei einem Canary Deployment wird die Bereitstellung des aktualisierten Codes auf einen kleinen Anteil der User beschränkt, die auf diese Weise unwissentlich an Tests in der Produktionsumgebung teilnehmen. Durch Verhaltens- und Nutzungsüberwachung können Sie vor einem flächendeckenden Deployment sicherstellen, dass die neue Version nicht zu Fehlern führt.

Einige Unternehmen gehen mit der Automatisierung noch einen Schritt weiter und nutzen einen sogenannten Canary-Konfidenzwert, der automatisch eine ganze Reihe von Kennzahlen mit Referenzwerten vergleicht. Der Rollout wird nur dann automatisch fortgesetzt, wenn der erreichte Wert eine bestimmte Schwelle überschreitet. Dabei können die ermittelten Kennzahlen als Ausgangspunkt für eine weitere Untersuchung potenzieller Probleme verwendet werden.

Ein Blue-Green-Build-Deployment-Prozess ist eine gängige Methode in Unternehmen, die ein Continuous-Deployment-System implementieren. Da der alte Code online bleibt, bis man sich sicher ist, dass die Änderungen wie erwartet funktionieren, ist es im Falle eines Problems einfacher, ein Rollback auf die Vorversion durchzuführen. Bei Bedarf kann ein Blue-Green-Rollout auf ein erstes Canary Deployment folgen.

Unabhängig davon, ob Sie ein Blue-Green-System verwenden oder direkte Rollouts durchführen, ist die Überwachung des Produktionssystems von entscheidender Bedeutung, um auf Fehler, die durch den Releaseprozess schlüpfen, schnell reagieren zu können.

Wenn Sie bestimmte Kennzahlen im Auge behalten, die den Zustand Ihres Systems anzeigen – von Speicherplatz und CPU-Auslastung bis hin zur Anzahl der Anfragen oder Transaktionen – und diese mit Referenzwerten vergleichen, werden Sie frühzeitig gewarnt, wenn sich die Dinge nicht so verhalten, wie sie sollten. Sie können dann entscheiden, ob Sie einen Rollback auf die Vorversion oder einen Roll-Forward in Form eines über die Pipeline bereitgestellten Bugfixes durchführen möchten.

Bevor Sie auf den Continuous-Deployment-Zug aufspringen, sollten Sie sich einen Moment Zeit nehmen und sich einige mögliche Probleme vor Augen führen, die bei der Einführung von CD auftreten können.

Der Softwareentwicklungszyklus umfasst mehr als nur Codeänderungen. Die Teams für Benutzerforschung, Produktmarketing, Interaktionsdesign, Dokumentation, Vertrieb, Recht und Support spielen ebenfalls wichtige Rollen.

Wenn Sie nicht mit allen Beteiligten gemeinsam das Fundament legen und herausfinden, welche unterschiedlichen Anforderungen an den Releaseprozess gestellt werden, kann sich die Einführung von Continuous Deployment für die anderen Teams so anfühlen, als wären bei der Entwicklungsabteilung die Zügel gerissen. Dies kann dazu führen, dass zur Verlangsamung des Prozesses manuelle Prüfpunkte und Überprüfungsphasen eingeführt werden, und es kann sogar passieren, dass das ganze Continuous-Deployment-System als fehlgeschlagenes Experiment abgelehnt wird.

Eine Kultur der Zusammenarbeit ist entscheidend. Die Einbeziehung anderer am Entwicklungsprozess beteiligter Teams, um ihre Inputs zu Design, Sicherheitsproblemen, Terminologie oder Compliance frühzeitig berücksichtigen zu können, ist ein Beispiel dafür, wie kurze Feedback-Schleifen den Softwareentwicklungszyklus effizienter machen. Genauso wichtig wie das Anfordern von Inputs ist die Transparenz darüber, was wann veröffentlicht wird. Mithilfe eines CI-Servers, eines Tools zur Continuous-Build-Deployment, der Informationen über Dashboards und Benachrichtigungen bereitstellt, lässt sich das Informieren der Beteiligten automatisieren.

Transparenz über kommende Releases ist jedoch manchmal nicht ausreichend. Wenn Sie an einem größeren Feature arbeiten oder das Timing der Releases steuern müssen, ist es nicht ideal, wenn jeder Commit nach Bestehen aller Tests einfach live geschaltet wird.

Feature-Flags sind eine Option zur Steuerung der Sichtbarkeit von Code in der Produktion. Der Vorteil ist dabei, dass der Code live ist und auf unerwartete Fehler überwacht werden kann. Ein anderer Ansatz besteht darin, einen dedizierten Branch zu verwenden, bei dem das Deployment über eine separate Pipeline erfolgt, deren Endpunkt nicht die Produktion ist. Dadurch können Continuous Delivery und Continuous Deployment nach Ihren Bedürfnissen kombiniert werden.

Bei richtiger Anwendung kann Continuous Deployment Teams dabei helfen, die Bereitstellung von Software für Benutzer*innen zu automatisieren. Die Einhaltung der Best Practices für Continuous Deployment kann Ihnen helfen, den Prozess zu optimieren und bessere Ergebnisse zu erzielen. So ist es zum Beispiel wichtig, dass Sie Ihre Pipeline regelmäßig überwachen und messen, um eventuelle Anzeichen von Problemen zu erkennen. Außerdem ist es sinnvoll, das gesamte Team einzubeziehen, um eine effektive CI/CD-Pipeline aufzubauen.

Die beiden Begriffe können leicht verwechselt werden, aber Continuous Deployment und Continuous Delivery sind beides unterschiedliche Teile der CD-Seite der CI/CD-Pipeline. While continuous delivery is focused on automating the steps required to deliver the software to users (for example, by automating builds, test automation, etc.), continuous deployment is a logical continuation of the process, automating the release of the software to end users provided that all necessary criteria are met.

Bei Continuous Deployment wird die Automatisierung optimal genutzt, um Features schnell bereitzustellen, ohne die Qualität zu beeinträchtigen. Grundlegend für diese DevOps-Methode ist ein regelmäßiges und schnelles Feedback. Automatisierte Tests, Produktionsüberwachung, Zusammenarbeit mit anderen Abteilungen und Informationen über das Benutzerverhalten liefern allesamt Inputs für den Softwareentwicklungsprozess. Indem Sie Ihre Arbeit in kleinere Stücke aufteilen und häufige Releases veröffentlichen, können Sie auf Feedback reagieren und Ihr Produkt kontinuierlich verbessern.