CI/CD und DevOps-Pipelines: Eine Einführung

Die CI/CD-Pipeline ist – vereinfacht ausgedrückt – ein Workflow für DevOps-Teams zur Automatisierung des Software-Bereitstellungsprozesses. CI/CD steht für Continuous Integration/Continuous Delivery (fortlaufende Integration/fortlaufende Verteilung). Dabei handelt es sich um ein Verfahren zur Softwareverteilung, das von Entwicklungsteams verwendet wird, um Codeänderungen häufiger und zuverlässiger zu verteilen. CI/CD umfasst zwei Sätze sich ergänzender Praktiken, die sich beide stark auf Automatisierung stützen.

Beim Continuous Integration-Prozess implementieren Entwicklungsteams kleine, regelmäßige Codeänderungen und führen sie in einem freigegebenen Repository zusammen. Moderne Anwendungen werden unter Einsatz vieler Tools und Plattformen entwickelt, sodass jede Codeänderung integriert und überprüft werden muss, damit sichergestellt ist, dass die Änderungen die Anwendung nicht beschädigen. Durch Continuous Integration wird der Prozess zum Erstellen, Verpacken und Testen von Code automatisiert, sobald ein Teammitglied in der Versionskontrolle protokollierte Änderungen am Code vornimmt. Dadurch wird es für Teams einfacher, Codeänderungen häufiger zu übertragen, sodass die Apps besser zusammenarbeiten und eine bessere Qualität haben.

Continuous Delivery ist eine Workflow-Engine, mit der Sie Prozesse wie das Testen auf Bugs und das Hochladen von Codeänderungen des Entwicklungsteams in ein Staging-Repository anstoßen können.

Der CI/CD-Prozess ist wichtig, da Verteilungsprozesse durch ihn einfacher und besser vorhersehbar werden. Darüber hinaus sorgt er für Konsistenz und Zuverlässigkeit im Software-Entwicklungsprozess, sodass Entwicklungsteams und Unternehmen besser zusammenarbeiten. Gleichzeitig werden die Kosten reduziert und die Anwendungen optimiert.

Dieser Artikel bietet eine kurze Einführung in den CI/CD-Pipeline-Prozess. Er erörtert die Einsatzmöglichkeiten sowie die besten Bereitstellungspraktiken und untersucht die zahlreichen Vorteile, die CI/CD für den Entwicklungslebenszyklus und letztendlich für euer gesamtes Unternehmen mit sich bringen kann.

Die DevOps-Grundlagen

DevOps ist ein Ansatz im Rahmen der IT-Bereitstellung, in dem Menschen, Praktiken und Tools miteinander kombiniert werden, um Hindernisse zwischen Entwicklungsteams und mit dem operativen Geschäft befassten Teams zu überwinden. DevOps überspannt die Lücke zwischen der Softwareentwicklung (bei der Anwendungscode erstellt wird) und dem operativen IT-Geschäft (bei dem diese Anwendungen in Produktion gehen, sodass sie Endbenutzern zur Verfügung gestellt und instandgehalten werden können). DevOps-Teams beschleunigen die Entwicklung von Anwendungen und Services und können in Kombination mit einem schnelleren Ansatz bei der Verwaltung der IT-Infrastruktur IT-Produkte bereitstellen und aktualisieren, um so in der Branche konkurrenzfähig zu bleiben. 

DevOps ist zum Teil aus der Agile-Entwicklungsbewegung als Möglichkeit zur Lösung eines ihrer größten Probleme entstanden– während agile Entwickler häufiger neue Apps und Code-Updates hervorbrachten, hatten herkömmliche Operations Teams Schwierigkeiten, sie zu testen und bereitzustellen, sodass der Wert einer schnellen Entwicklung in Frage gestellt wurde. Durch die Ausweitung der Agilitätsgrundsätze auf den gesamten Lebenszyklus der Softwareentwicklung (SDLC) ist DevOps in der Lage, den gesamten Arbeitsablauf kontinuierlich zu optimieren. Leistungsstarke DevOps-Teams freuen sich nicht nur über schnellere Code-Iterationen und Bereitstellungen, sondern auch über insgesamt kürzere Markteinführungszeiten für neue Ideen, weniger Bugs und eine stabilere Infrastruktur.

CI/CD ist ein grundlegender Prozess in DevOps. Entwickler fügen regelmäßig – oft täglich – neuen Code in den Hauptquellcode ein. Während dieser neue Code in ein zentrales, gemeinsam genutztes Repository eingecheckt wird, testet und validiert ein automatisierter Build-Prozess die Änderungen, sodass die Entwickler Probleme schnell erkennen und sofort Feedback erhalten, um notwendige Anpassungen vornehmen zu können.

Was ist der CI/CD-Pipelineprozess?

Die CI/CD-Pipeline ist im Wesentlichen ein Workflow, der einen Weg bietet, über den DevOps-Teams den Softwarebereitstellungsprozess automatisieren. Ohne eine automatisierte Pipeline müssten die Teams ihren Workflow manuell konfigurieren, was zeitaufwändig und fehlerträchtig wäre. Die CI/CD-Pipeline beseitigt manuelle Fehler, standardisiert die Feedbackschleifen der Entwickler und erhöht das Tempo der Produktiterationen.

Vorläufer von CI/CD sind die automatisierte Release-Automatisierung (ARA) und das automatisierte Release-Management (ARM), die beide in die Arbeitskategorie „Release-Automatisierung“ fallen und neue Wegmarken der sich entwickelnden automatisierten Prozesse und Trends in diesem Bereich darstellen.

Es gibt keine Standardverfahren oder -implementierung für eine CI/CD-Pipeline, und jedes DevOps-Team wählt die Tools und Dienste aus, die es für den Aufbau seiner Pipeline verwendet. In der Regel umfasst eine Pipeline jedoch die folgenden Phasen:

• Quellphase: Entwickler checken den Quellcode einer Anwendung aus, der in einem zentralen Repository wie GitHub gespeichert ist, und arbeiten lokal daran. Sie erstellen einen neuen Zweig für eine Funktion oder einen zu behebenden Fehler und führen lokal in ihrer Entwicklungsumgebung Tests durch, bevor sie ihn in das Quellcode-Repository zurückübertragen.
• Build-Phase: Neu in das Quell-Repository übertragener Code löst die Build-Phase aus, in der die Zweig-Codes gesammelt und kompiliert werden, um eine lauffähige Version zu erstellen. Entwickler können ihre Releases mehrmals am Tag erstellen und testen, um Fehler im Code zu erkennen und Benachrichtigungen zu erhalten, wenn ein Build fehlschlägt oder andere Probleme auftreten, damit das Team so schnell wie möglich einen Fix implementieren kann. Sobald der Code fehlerfrei ist, geht er in die nächste Phase über.
• Testphase: Der Build durchläuft mehrere Tests zur Validierung des Codes, in denen sichergestellt wird, dass er sich so verhält, wie er soll. Meistens gehören dazu zum einen Komponententests (Unit Tests), bei denen die Anwendung in kleine Code-Einheiten zerlegt wird, die dann einzeln getestet werden. Ferner gehören Benutzerakzeptanztests (User Acceptance Testing, UAT) dazu, bei denen Benutzer die Anwendung verwenden, um festzustellen, ob der Code vor dem Einsatz in der Produktion noch geändert werden muss. In dieser Phase können auch Last-, Sicherheits- und andere kontinuierliche Tests stattfinden.
• Verteilungsphase: Für produktionsreife Anwendungen gibt es viele verschiedene Verteilungsstrategien. Welche die beste ist, richtet sich nach der Art der Anwendung, dem Grad der Überarbeitung, der Zielumgebung und anderen Faktoren. Im Folgenden stellen wir moderne Verteilungsansätze für Cloud-Anwendungen vor.
  • Rollierende Verteilung: Diese Methode liefert die aktualisierte Anwendung schrittweise aus, bis alle Ziele über die aktualisierte Version verfügen. Bei der rollierenden Verteilung ist die Gefahr von Ausfallzeiten geringer, und sie lassen sich leicht rückgängig machen. Sie erfordern jedoch Dienste, die sowohl die neue als auch die alte Version der App unterstützen.
  • Blue-Green-Deployment: Bei dieser Methode betreiben Entwickler zwei Versionen der App parallel auf getrennten Infrastrukturen. Die letzte stabile Version der App läuft in der Produktionsumgebung (blau) und die neue Version in einer Staging-Umgebung (grün). Die grüne Version der App wird auf Funktionalität und Leistung getestet, und wenn sie diese Tests besteht, wird der Datenverkehr von der blauen Umgebung in die grüne Umgebung verlagert, die zur neuen Produktionsumgebung wird. Blue-Green Deployments lassen sich schnell und einfach implementieren, können aber kostspielig sein, wenn die replizierte Produktionsumgebung besonders komplex ist.
  • Canary Deployment: Bei diesem Verteilungsmodell geben die Entwickler eine Anwendung für eine kleine Gruppe von Benutzern frei, die sie verwenden und Feedback geben. Sobald bestätigt ist, dass die aktualisierte App korrekt funktioniert, wird sie an die übrigen Benutzer verteilt. Die Strategie ermöglicht es Entwicklern, zwei Versionen einer App mit echten Benutzern gleichzeitig zu testen. Außerdem ermöglicht sie Updates und Rollbacks ohne Ausfallzeiten.

In jeder Phase der Pipeline erhält das Entwicklungsteam Benachrichtigungen zu Fehlern und kann daher Probleme sofort beheben. Die Codeänderungen durchlaufen die Pipeline erneut, sodass nur fehlerfreier Code in der Produktion bereitgestellt wird.

Continuous Deployment vs. Continuous Delivery

Continuous Deployment ist der Verteilvorgang, bei dem Codeänderungen in der Produktionsumgebung automatisiert veröffentlicht werden. Er wird ausgelöst, nachdem neuer Code integriert und durch Continuous Integration und Continuous Delivery genehmigt wurde. Die Codeänderungen durchlaufen eine Reihe automatisierter Tests und werden, nachdem die Tests bestanden wurden, sofort an die Benutzer der Software weitergegeben.

Continuous Deployment hört sich zwar wie ein Synonym für Continuous Delivery an – und beide werden auch häufig mit „CD“ abgekürzt –, aber es handelt sich um eine separate Praktik. Continuous Delivery ist ein Lieferprozess, der neue Builds automatisch in eine automatisierte QS-Testumgebung pusht, in der nach Bugs und anderen Problemen gesucht wird. Sobald die Tests bestanden werden, wird der Build zur Verteilung genehmigt und automatisch per Push an die Endbenutzer übertragen. Da in dieser letzten Phase keine Pause für menschliche Vermittlung erforderlich ist, wird sie auch als Continuous Deployment bezeichnet.

Continuous Deployment weitet zwar die Agilität und Geschwindigkeit von CI/CD aus, bringt aber eigene Risiken mit sich, da zwischen den abschließenden Tests und der Veröffentlichung für die Benutzer kein manuelles Eingreifen vorgesehen ist. Aufgrund dieses Problems eignet sich das Verfahren nicht gut für Software, bei der die Sicherheit vertraulicher Daten, die Einhaltung von Vorschriften oder hohe finanzielle Einsätze auf dem Spiel stehen.

Wie wird CI/CD verwendet?

CI/CD wird verwendet, um die Softwareentwicklung zu rationalisieren und zu automatisieren, um Apps und Services schneller und häufiger bereitzustellen. CI/CD erreicht dies größtenteils durch Automatisierung, durch die Tests, Feedback, Codekorrekturen und Verteilung beschleunigt werden.

Die Implementierung von CI/CD-Praktiken bietet viele Vorteile:

• Schnellere und robustere Releases: Der offensichtlichste Vorteil von CI/CD besteht darin, dass es die Softwareverteilung beschleunigt und den Prozess effizienter macht. Durch die Automatisierung der meisten Tests und großer Teile der Fehlerbehebung können sich die Entwickler verstärkt auf das Schreiben von Code und die Verbesserung der Anwendungsqualität konzentrieren.
• Frühere Fehlererkennung: Dank der automatisierten Tests in jeder Phase der CI/CD-Pipeline können Entwickler Bugs und andere Probleme identifizieren, sobald sie auftreten – wobei die meisten bereits in frühen Phasen erkannt werden –, und so potenziell verheerende Überraschungen bei der Verteilung vermeiden.
• Größere Transparenz: Mit einer CI/CD-Pipeline können Entwicklungsteams Builds sowie Testergebnisse und Codierungsfehler sehr detailliert analysieren. Dadurch verstehen sie besser, welche Build-Änderungen zu Problemen und Ineffizienzen geführt haben, sodass sie darauf vorbereitet sind, diese Probleme in Zukunft zu vermeiden.
• Schnellere Feedback-Schleifen: CI/CD richtet eine konstante Schleife für Benutzerfeedback ein, die Entwickler zu ihrem Vorteil nutzen können, um mit Funktionen zu experimentieren und das App-Erlebnis zu verbessern.
• Geringere Kosten: Der automatisierte Ansatz von CI/CD reduziert die Anzahl der Fehler in jeder Phase des Entwicklungsprozesses und vereinfacht die Behebung auftretender Probleme. Entwickler müssen keine Zeit mehr für banale, manuelle Aufgaben aufwenden und können sich so auf die Verbesserung der Codequalität und der Apps konzentrieren, was den ROI steigert.
• Höhere Kundenzufriedenheit: Zuverlässigere Releases und schnellere Durchlaufzeiten für Updates, Fehlerbehebungen und neue Funktionen bewirken, dass Kunden sich für euch und nicht für die Konkurrenz zu entscheiden.

Best Practices für die CI/CD-Pipeline-Bereitstellung

Jede Orchestrierung und Implementierung einer CI/CD-Pipeline ist ein wenig anders. Nachfolgend finden Sie jedoch einige grundlegende Richtlinien, die Ihnen dabei helfen sollen, häufig auftretende Probleme zu lösen und die effektivste Pipeline für Ihr Unternehmen zu unterhalten:

• Verwendet eine konsistente Umgebung: Eine zuverlässige CI/CD-Pipeline wird für eine bestimmte Eingabe immer die gleiche Ausgabe erzeugen. Ihr habt jedoch keine zuverlässige Pipeline, wenn jeder Durchlauf die Pipeline-Umgebung verändert. Startet deshalb jeden Workflow aus derselben isolierten Umgebung.
• Setzt Pipeline-Analysen ein: Pipeline-Analysen visualisieren Telemetriedaten aus euren CI/CD-Prozessen, erweitern die Transparenz und erhöhen die Messmöglichkeiten. So erfahrt ihr, wie gut eure Bereitstellungs-Pipeline funktioniert.
• Frühzeitiges und häufiges Commitment erleichtert die Identifizierung von Fehlern, da weniger Code durchsucht werden muss. Dieser Ansatz der kleinen Schritte verbessert die Codequalität und ermöglicht Teams effektivere Iterationen.
• Einmaliges Erstellen: Erfolgreiche CI/CD-Pipelines beinhalten normalerweise den Build-Prozess als ersten Schritt im CI/CD-Zyklus. Dieser Schritt erfolgt nur einmal, wobei das Ergebnis in der gesamten Pipeline zum Einsatz kommt. Die Wiederverwendung eines einzelnen Builds verhindert neu auftretende Inkonsistenzen beim Durchlaufen der Pipeline-Phasen.
• Versionskontrollen einführen: Ein Versionskontrollsystem ist unerlässlich, um Quellcode zu speichern, Codeänderungen nachzuverfolgen und bei Bedarf auf frühere Versionen zurückzugreifen. Stellt sicher, dass ihr die Versionskontrolle für Skripte, Dokumentation, Bibliotheken und Konfigurationen anwendet.
• Inkrementell entwickeln: Die Arbeit in kleinen Schritten – das Aufteilen einer Funktion in kleinere Teilfunktionen und die Verwendung eindeutiger Feature-Flags – erleichtert das Isolieren von Problemen. Das reduziert auch das Risiko von Integrationsproblemen, wenn die Funktion im Produktionsprozess landet.
• Überwacht eure Pipelines: Die Korrelation eurer Pipeline-Daten mit anderen Metriken hilft dabei, die Gesamtleistung eurer Anwendungen zu optimieren. Erfahrt mehr über CI/CD-DevOps-Pipeline-Monitoring

So implementiert ihr den CI/CD-Prozess

Beim Implementieren eines CI/CD-Prozesses gilt es einige Dinge zu beachten:

• Ihr müsst verstehen, dass CI/CD ein Workflow- und Bereitstellungsprozess ist, kein Produkt. Vermeidet es, euch in Vorstellungen vom „richtigen Tool“ zu verstricken. Das Ziel des CI/CD-Prozesses ist es, die Software-Entwicklung von einem manuellen, umständlichen und langsamen Prozess in einen automatisierten, schlanken und schnellen Vorgang zu verwandeln. Identifiziert einen Ausgangspunkt und stellt dann ein engagiertes Team aus Entwicklern und Betriebsmitarbeitern zusammen, um das Konzept zu überprüfen, bis eure Pipeline funktioniert.
• Plant für den Erfolg: Von Anfang an ist umfangreiche technische Planung erforderlich, einschließlich der Auswahl von Plattformen und der Überarbeitung von Anwendungen, damit iterative Aktualisierungen besser klappen. Es wird jedoch auch kulturelle Überlegungen geben, wenn sich eure Implementierung auf die größere Organisation erstreckt. Die Unterstützung von IT und Geschäftsleitung entscheidet über den langfristigen Erfolg.
• Optimiert eure Prozesse: Nehmt euch Zeit, um eure aktuellen Prozesse und Arbeitsabläufe zu bewerten, bevor ihr CI/CD-Tools in bestehende Bereitstellungs-Pipelines integriert. Wenn diese nicht effektiv arbeiten, wird die Automatisierung keine Erfolgsgeschichte. Stellt deshalb sicher, dass sie in Ordnung sind, bevor ihr sie in die neue CI/CD-Pipeline einbaut.
• Legt Wert auf kontinuierliche Verbesserungen: Geht CI/CD mit der Einstellung an, aus Fehlern zu lernen und euch stetig zu verbessern. Es ist deshalb wichtig, dass eure CI/CD-Tools kontinuierliche Metriken liefern, die sich in ein gemeinsames Dashboard integriert lassen. Dann können alle Beteiligten den Fortschritt verfolgen und feststellen, welche Anpassungen wo vorgenommen werden müssen.

Aufbau von CI/CD auf GCP und AWS

AWS (Amazon Web Services) und GCP (Google Cloud Platform) sind zwei beliebte DaaS-Optionen (DevOps-as-a-Service). Beide haben spezielle Vor- und Nachteile.

AWS ist in der Regel schnell, bietet eine einfache Möglichkeit, Ihr DevOps in die Cloud zu migrieren und arbeitet mit einem bequemen nutzungsorientierten Abrechnungsmodell. GCP stellt eine Fülle von Tools wie Stackdriver Monitoring, Stackdriver Debugger, Stackdriver Logging und einen Sicherheits-Scan-Service (App Engine) zur Verfügung, die Sie in Ihrer Anwendungslebenszyklus-Pipeline nutzen können.

Beide bieten hochwertige DevOps-Lösungen, sodass sich die Unterscheidungsmerkmale auf den Preis und die Einsatzbereiche beschränken.

Überlegungen zu CI/CD-Toolchains

Bei der Suche nach CI/CD-Tools zum Hinzufügen zu Ihrer Entwicklungs-Toolchain gilt es einige Dinge zu beachten.

Das erste ist die Frage, ob Sie ein Open-Source-CI/CD-Tool im Gegensatz zu einem kommerziellen Tool (es liefert den Code) verwenden oder Ihr eigenes entwickeln möchten. Eine Open-Source-Lösung spart Geld, aber es besteht das Risiko, dass die Entwickler den Code drastisch verändern oder die Entwicklung des Produkts ganz einstellen. Außerdem wird für Open-Source-Tools oftmals nur minimaler Support geboten. Kommerzielle Tools bieten dagegen in der Regel einen starken Support und besser vorhersehbare Update-Zyklen, können aber auch kostspielig sein und eine weniger flexible Integration bieten. Wenn Sie Ihre eigene Lösung entwickeln, können Sie sie an die speziellen Anforderungen Ihres Unternehmens anpassen. Allerdings erfordert sie viele Ressourcen.

Eine weitere Überlegung gilt dem Hosting-Modell. Wenn Ihre Codebasis vor Ort bleiben muss, benötigen Sie eine Toolchain, die Sie auf Ihren eigenen Servern oder in Ihrer virtuellen Infrastruktur einsetzen können. CI/CD-Tools sind jedoch überwiegend auf Cloud- und Cloud-native Infrastrukturen ausgerichtet, sodass CI/CD-Tools auch als Teil eines SaaS-Modells (Software-as-a-Service) angeboten werden, das auf der Cloud-Infrastruktur des Anbieters läuft, wodurch Sie weite Teile der Supportkosten auslagern können.

Wie auch immer Sie diese Fragen beantworten, Sie müssen auch die damit verbundenen Kosten berücksichtigen. Trotz der anfänglichen Einsparungen bei einem Open-Source-Tool entstehen Ihnen Kosten für die Einrichtung und den Support des Tools in Ihrer Infrastruktur sowie ein gewisser Produktivitätsverlust, solange die Entwickler lernen, damit umzugehen. Bei kommerziellen Standard- und SaaS-Tools zahlen Sie in der Regel eine Gebühr, die sich nach Ihrem Nutzungsverhalten richtet.

Welche Option für Ihr Unternehmen die beste ist, hängt davon ab, wie viele Builds Sie erstellen möchten, ob Sie parallele Builds benötigen und wie viele Benutzer auf das Tool zugreifen sollen.

Fazit: Bringen Sie Ihr Unternehmen mit CI/CD auf die nächste Stufe

Die Geschwindigkeit, mit der ihr Software ausliefert, gilt als wichtiges Unterscheidungsmerkmal im Markt. Erfolgreiche Unternehmen schaffen 50 bis 100 Deployments pro Tag, wobei einige Giganten wie Netflix sogar über 1.000 erreichen. Eine funktionale CI/CD-Pipeline fördert die Produktivität, Zuverlässigkeit und Geschwindigkeit, um diese Zahlen zu erreichen. Stabile Anwendungen sind notwendig, um sich ständig ändernde Geschäftsanforderungen zu erfüllen. Einfach ausgedrückt: Wenn ihr keine CI/CD-Praktiken befolgt, lauft ihr Gefahr, dass eure Firma den Anschluss verliert. Die Transformation eurer Software-Bereitstellung geht weder schnell noch einfach, aber der Aufwand lohnt sich. Dann ist euer Unternehmen für die kommenden Jahre gut aufgestellt.