DevOps-Pipeline

1. Continuous Integration/Continuous Delivery/Deployment (CI/CD)

Continuous Integration bezeichnet ein Verfahren, bei dem häufige Commits in ein gemeinsames Quellcode-Repository ausgeführt werden. Hierbei geht es um die kontinuierliche Integration von Codeänderungen in die vorhandene Codebasis, sodass Konflikte zwischen Codeänderungen von verschiedenen Entwicklern schnell erkannt werden und relativ einfach behoben werden können. Diese Vorgehensweise ist entscheidend für die Steigerung der Deployment-Effizienz.

Unserer Meinung nach ist die Trunk-basierte Entwicklung eine Voraussetzung für Continuous Integration. Wenn du in einem freigegebenen Quellcode-Repository keine häufigen Commits zu einem gemeinsamen Branch ausführst, ist das keine Continuous Integration. Wenn deine Build- und Testprozesse automatisiert sind, deine Entwickler jedoch an isolierten, langlebigen Feature-Branches arbeiten, die selten in einen gemeinsamen Branch integriert werden, ist das ebenfalls keine Continuous Integration.

Continuous Delivery stellt sicher, dass der Haupt- oder Trunk-Branch des Quellcodes einer Anwendung immer in einem releasefähigen Zustand ist. Anders ausgedrückt heißt das: Wenn das Management an einem Freitag um 16:30 Uhr an deinen Schreibtisch käme und sagen würde: "Wir müssen die neueste Version jetzt veröffentlichen", könnte diese Version auf Knopfdruck bereitgestellt werden – und das, ohne Angst vor Fehlern oder Ausfällen.

Deshalb solltest du eine Vorproduktionsumgebung haben, die mit der Produktionsumgebung nahezu identisch ist. So stellst du sicher, dass automatisierte Tests ausgeführt werden und dadurch jede Variable identifiziert wird, die einen Fehler verursachen könnte, bevor Code in den Haupt- oder Trunk-Branch gemergt wird.

Continuous Deployment bedeutet, dass ein Maß an kontinuierlichen Tests und Abläufe erreicht wird, das so stabil ist, dass neue Softwareversionen ohne menschliches Eingreifen validiert und in einer Produktionsumgebung bereitgestellt werden können.

Dies geschieht jedoch selten und ist in den meisten Fällen überflüssig. In der Regel sind es nur die Unternehmen mit Einhorn-Status, die Hunderte oder Tausende von Entwicklern haben und täglich viele Releases herausbringen, die ein solches Maß an Automatisierung benötigen oder sogar wünschen.

Um den Unterschied zwischen Continuous Delivery und Continuous Deployment zu verdeutlichen, stell dir die Delivery so vor, dass dir dein Postbote ein Paket übergibt, und das Deployment so, dass du das Paket öffnest und seinen Inhalt nutzt. Wenn zwischen dem Erhalt und Öffnen des Pakets eine Änderung des Produkts erforderlich wird, hat der Hersteller ein großes Problem!

2. Fortlaufendes Feedback

Der größte Schwachpunkt der alten Wasserfallmethode in der Softwareentwicklung – und der Grund, weshalb agile Methoden entwickelt wurden – war das Fehlen von zeitnahen Rückmeldungen. Wenn es Monate oder Jahre dauert, bis Features von der ersten Idee bis zur Implementierungsphase gelangen, konnte das Ergebnis einfach nicht mehr den Erwartungen der Kunden entsprechen. Mit agilen Methoden konnte sichergestellt werden, dass Entwickler schneller Feedback von Stakeholdern erhielten. Mit DevOps erhalten Entwickler jetzt kontinuierliches Feedback nicht nur von Stakeholdern, sondern auch durch systematische Tests und die Überwachung ihres Codes in der Pipeline.

Kontinuierliche Tests sind eine kritische Komponente jeder DevOps-Pipeline und eine der wichtigsten Voraussetzungen für kontinuierliches Feedback. In einem DevOps-Prozess verlagern sich Änderungen kontinuierlich von der Entwicklung über das Testen bis hin zum Deployment, was nicht nur zu schnelleren Releases, sondern auch zu einem qualitativ hochwertigeren Produkt führt. Dies bedeutet, dass du automatisierte Tests in deiner gesamten Pipeline durchführen musst, wie Unit-Tests, die bei jeder Build-Änderung ausgeführt werden, sowie Smoke-Tests, Funktionstests und End-to-End-Tests.

Kontinuierliche Überwachung ist ein weiterer wichtiger Bestandteil des kontinuierlichen Feedbacks. Ein DevOps-Ansatz umfasst die kontinuierliche Überwachung in den Staging-, Test- und sogar Entwicklungsumgebungen. Manchmal ist es sinnvoll, Vorproduktionsumgebungen auf anomales Verhalten zu überwachen. Doch im Allgemeinen wird dieser Ansatz für die kontinuierliche Bewertung des Zustands und der Leistung von Anwendungen in der Produktion genutzt.

Es gibt zahlreiche Tools und Services, um diese Funktionalität bereitzustellen. Und dies kann alles umfassen – von der Überwachung deiner Vor-Ort- oder Cloud-Infrastruktur wie Serverressourcen, Netzwerke usw. oder der Leistung deiner Anwendung oder ihrer API-Schnittstellen.

3. Continuous Operations

Continuous Operations ist ein relativ neuer und weniger gebräuchlicher Begriff, der unterschiedlich definiert wird. Man könnte ihn einerseits als "kontinuierliche Verfügbarkeit" interpretieren. Das ist beispielsweise bei einer Blau/Grün-Deployment-Strategie der Fall, bei der du zwei separate Produktionsumgebungen hast: eine "blaue" (öffentlich zugänglich) und eine "grüne" (nicht öffentlich zugänglich). In dieser Situation würde neuer Code in der grünen Umgebung bereitgestellt. Und wenn sich dieser als funktionsfähig erweist, würde ein Schalter umgelegt (normalerweise auf einem Load Balancer) und der Datenverkehr vom blauen System zum grünen umgeleitet. Auf diese Weise gibt es keine Ausfallzeiten für die Endbenutzer.

Man kann Continuous Operations aber auch als kontinuierliche Alarmierung auffassen. Dabei wird davon ausgegangen, dass Techniker Bereitschaftsdienst haben und benachrichtigt werden, wenn in der Anwendung oder Infrastruktur Leistungsanomalien auftreten. In den meisten Fällen geht die kontinuierliche Alarmierung mit einer kontinuierlichen Überwachung einher.