Continuous Deployment

Was ist Continuous Deployment (kontinuierliche Bereitstellung)?

Um flexibel bleiben zu können, muss man schnell und effizient reagieren können, insbesondere bei der Softwareentwicklung.

Continuous Deployment (kontinuierliche Bereitstellung) und Continuous Delivery (kontinuierliche Auslieferung) sind zwei Begriffe, die so oft zusammen verwendet werden, dass sie möglicherweise synonym verwendet werden.

Das kann zu Verwirrung führen. Beide beziehen sich darauf, wie Features in die Produktion gebracht werden. Es gibt jedoch einen wesentlichen Unterschied zwischen den beiden.

Bei der Continuous Delivery muss jemand die Freigabe des Features für die Produktion genehmigen, bei Continuous Deployment geschieht dieser Prozess jedoch automatisch nach der Prüfung durch automatisierte Tests. Das Continuous Deployment basiert im Wesentlichen auf einer vollautomatisierten Pipeline.

Alle manuellen Schritte sind vollständig eliminiert und der gesamte Prozess ist automatisiert. Daher stellt Continuous Deployment sicher, dass der Code kontinuierlich in die Produktion gepusht wird.

Echtzeitüberwachung ist jedoch weiterhin erforderlich, um auftretende Probleme während der automatisierten Tests zu verfolgen und zu beheben sowie sicherzustellen, dass die Builds diese Tests bestanden haben.

CI/CD und CD Prozess

Das Continuous Deployment ist Teil eines kontinuierlichen Prozesses. Der erste Schritt beginnt mit der Continuous Integration (kontinuierliche Integration), wenn Developer ihre Änderungen häufig in den Hauptzweig oder die Hauptlinie integrieren. Dies hilft Teams, der sogenannten „Merge Hell“ zu entgehen, die auftritt, wenn Developer versuchen, mehrere separate Zweige unregelmäßig in den gemeinsamen Hauptzweig zu integrieren.

Dann folgt die Continuous Delivery, wenn Code in einer Test- oder Produktionsumgebung bereitgestellt wird. Hier werden die Änderungen der Developer in ein Repository hochgeladen, von wo aus sie dann in einer Produktionsumgebung bereitgestellt werden.

Mit der Continuous Delivery kann man sich entscheiden, täglich, wöchentlich oder monatlich zu veröffentlichen, es wird jedoch normalerweise empfohlen, so oft wie möglich in kleinen Batches zu veröffentlichen, um eventuelle Probleme leicht und schnell beheben zu können.

Das Continuous Deployment geht noch einen Schritt weiter und kombiniert Continuous Integration und Continuous Delivery, um Software automatisch für User verfügbar zu machen, ohne dass menschliches Eingreifen erforderlich ist. Daher erfordert das Continuous Deployment vollständige Automatisierung aller Bereitstellungen und bezieht sich somit auf den Prozess der automatischen Freigabe von Developer-Änderungen aus dem Repository in die Produktion, ohne dass eine Developer-Genehmigung für jede Freigabe erforderlich ist. Folglich hängt dieser Prozess stark von gut gestalteter Testautomatisierung ab.

Alle diese Praktiken kommen zusammen, um Releases zu erleichtern und zu beschleunigen. Dadurch wird auch die Bereitstellung weniger riskant.

Vorteile des Continuous Deployment

In diesem Sinne beschleunigt das Continuous Deployment die Markteinführung und beschleunigt auch den Feedbackprozess mit sowohl Developern als auch Kunden.

Die Arbeit der Developer geht fast sofort nach Abschluss live. Auf diese Weise können Developer in Echtzeit auf Feedback und Fehlerberichte reagieren oder eine neue Idee testen, indem sie schnell neue Features bereitstellen und validieren. Continuous Deployment nimmt auch den Druck des Veröffentlichungstags weg, sodass sich Developer ausschließlich auf den Aufbau der Software konzentrieren können, die automatisch innerhalb weniger Minuten live geht.

Es folgt eine Steigerung der Produktivität und Developer können schnell auf sich ändernde Marktanforderungen reagieren. Continuous Deployment erfordert jedoch ein hohes Maß an Überwachung und Wartung, um sicherzustellen, dass es reibungslos läuft. Zudem musst man in der Lage sein, schnell auf Änderungen reagieren zu können.

Features Flags und Continuous Deployment

Wir können schlussfolgern, dass Teams, die Continuous Deployment praktizieren, sehr gründlich in ihren automatisierten Testpraktiken sein müssen, da alle Releases automatisch ohne vorherige Genehmigung erfolgen.

Daher werden alle Fehler, die diese Tests umgehen, an die User weitergegeben. Diese Herausforderung kann durch die Verwendung von Feature Flags gelöst werden, da sie eine zusätzliche Sicherheitsebene zum Prozess der Continuous Delivery hinzufügen. Ein Kill Switch kann auf jedes Feature gesetzt werden, sodass bei erkannten Fehlern das Feature nicht zurückgerollt werden muss, sondern einfach das Feature Toggle ausgeschaltet wird.

Auf diese Weise werden die Teile des Features, die nicht wie vorgesehen funktionieren, nicht den Usern vorgesetzt, während der Rest der Änderungen des Features ohne Notwendigkeit eines Rollbacks veröffentlicht werden kann.

Kurze Zusammenfassung

In summary:

• Continuous integration (CI): integrate changes to a shared trunk several times a day.
• Continuous delivery (CD): continuous integration then deploy all code changes to production environment; deployment is manual.
• Continuous deployment (CD): step further from continuous delivery; automated deployment to production without any need for developer approval.

CI/CD, then, can be taken to refer to the connectedness of the continuous integration and delivery processes or it can even refer to all three practices of continuous integration, continuous delivery and continuous deployment.

In the end, what’s important to remember is CI/CD, visualized as a pipeline, automates the software delivery process by building code, running tests and deploying this code to a live production environment.