Was ist eine CI/CD-Pipeline? 

Was ist der Unterschied zwischen Continuous Integration und Continuous Delivery?

Beim Prozess der Continuous Integration (CI) implementieren Entwicklungsteams kleine, regelmäßige Code-Änderungen und führen sie in einem freigegebenen Repository zusammen. Moderne Anwendungen werden unter dem 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 regelmäßiger zu übertragen, sodass die Zusammenarbeit und die App-Qualität verbessert werden.

Im Gegensatz zur Continuous Integration handelt es sich bei der Continuous Delivery (CD) um 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.

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 die Vorteile der schnellen Entwicklung nicht zum Tragen kamen. Durch die Ausweitung der Agilitätsgrundsätze auf den gesamten Lebenszyklus der Softwareentwicklung (SDLC) ermöglicht es DevOps, 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 im Rahmen von DevOps-Verfahren. 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.

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 fehleranfällig 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 (Automated Release Automation, ARA) und das automatisierte Release-Management (Automated 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 -implementierungen 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 braucht. 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: Neuer Code, der in das Quellcode-Repository übertragen wird, löst die Build-Phase aus, in der die Codes der Zweige gesammelt und kompiliert werden, um eine lauffähige Instanz der jeweiligen Releases 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 der Bereitstellung noch geändert werden muss. Last-, Sicherheits- und andere kontinuierliche Tests können in dieser Phase durchgeführt werden.

Verteilungsphase: Wenn die Anwendung für die Produktion bereit ist, gibt es viele verschiedene Verteilungsstrategien, die zur Wahl stehen. Welche Wahl die beste ist, richtet sich nach der Art der Anwendung, dem Grad der Überarbeitung, der Zielumgebung und anderen Faktoren. Im Folgenden sind moderne Verteilungsansätze für Cloud-Anwendungen aufgeführt. 

• Rollierende Verteilung: Bei dieser Methode wird die aktualisierte Anwendung inkrementell verteilt, bis alle Ziele über die aktualisierte Version verfügen. Bei der rollierenden Verteilung ist die Gefahr von Ausfallzeiten geringer, und sie lassen sich leicht zurücksetzen. Jedoch erfordern sie Services, die sowohl die neue als auch die alte Version der App unterstützen.
• Blue-Green Deployment (Blau-Grün-Verteilung): Bei dieser Methode führen die Entwickler zwei Versionen der App parallel auf getrennten Infrastrukturen aus. Die letzte stabile Version der App wird in der Produktionsumgebung (blau) und die neue Version in einer Staging-Umgebung (grün) ausgeführt. 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 (Canary-Verteilung): Bei diesem Verteilungsmodell geben die Entwickler eine Anwendung für eine Untergruppe 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. Diese Strategie ermöglicht es den Entwicklern, zwei Versionen einer App mit echten Benutzern nebeneinander zu testen. Ferner ermöglicht sie Updates und Rollbacks ohne Ausfallzeiten.
  

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

CI/CD ist ein grundlegender Prozess im Rahmen von DevOps-Verfahren. 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 mithilfe einer DevOps-Pipeline schnell erkennen und sofort Feedback erhalten, um notwendige Anpassungen vornehmen zu können.

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 (CI) und Continuous Delivery (CD) 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 Delivery-Prozess, der neue Builds automatisch in eine automatisierte QS-Testumgebung leitet, in der nach Bugs und anderen Problemen gesucht wird. Sobald die Tests bestanden werden, wird der Build zur Verteilung genehmigt und automatisch an die Endbenutzer übertragen. Da in dieser letzten Phase keine Pause für menschliches Eingreifen 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 Continuous-Deployment-Verfahren nicht für Software, bei der die Sicherheit vertraulicher Daten wichtig ist, Compliance-Vorschriften eingehalten werden müssen oder hohe finanzielle Einsätze auf dem Spiel stehen.

Die Implementierung von CI/CD -Praktiken bietet dabei zahlreiche 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 CI/CD-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 der Fehler, die dennoch auftreten. Die CI/CD-Entwickler müssen keine Zeit mehr für banale, manuelle Aufgaben aufwenden und können sich so auf die Verbesserung der Codequalität und auf Verbesserungen der Apps konzentrieren, die den ROI verstärken.

Höhere Kundenzufriedenheit: Zuverlässigere Releases und schnellere Durchlaufzeiten für Updates, Fehlerbehebungen und neue Funktionen bewirken, dass Kunden Sie der Konkurrenz vorziehen.

Jede Orchestrierung und Implementierung einer CI/CD-Pipeline ist unterschiedlich. 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 nutzen:

Verwenden einer konsistenten Umgebung: Eine zuverlässige CI/CD-Pipeline erzeugt für eine bestimmte Eingabe immer dieselbe Ausgabe. Sie erhalten jedoch keine zuverlässige Pipeline, wenn sich die Umgebung der Pipeline mit jedem Durchlauf ändert. Achten Sie also darauf, dass Sie jeden Workflow aus derselben isolierten Umgebung starten.

Anwenden von Pipeline-Analysen: Mithilfe von Pipeline Analysen werden die Telemetriedaten aus Ihren CI/CD-Prozessen visualisiert, sodass sich die Transparenz erhöht und die Messmöglichkeiten vergrößern. Auf diese Weise erfahren Sie, wie gut Ihre Continuous-Delivery-Pipeline funktioniert.

Frühzeitige und häufige Anpassungen: Die frühe und häufige Durchführung von Änderungen vereinfacht die Erkennung von Bugs, einfach weil weniger Code durchkämmt werden muss. Dieser Ansatz der kleinen Batches verbessert die Codequalität und ermöglicht Teams ein effektiveres Iterieren.

Einmaliger Build: Erfolgreiche CI/CD-Pipelines beinhalten in der Regel den Build-Prozess als ersten Schritt im CI/CD-Zyklus. Der Schritt wird nur einmal ausgeführt, und die resultierende Ausgabe wird in der gesamten Pipeline verwendet. Durch die Wiederverwendung eines einzelnen Builds werden neu eingeführte Inkonsistenzen auf dem Weg durch die einzelnen Phasen der Pipeline vermieden.

Implementieren von Versionskontrollen: Ein Versionskontrollsystem ist unerlässlich, um Quellcode zu speichern, Codeänderungen aufzuzeichnen und bei Bedarf auf frühere Bereitstellungen zurückzugehen. Wenden Sie auf Skripts, Dokumentationen, Bibliotheken und Konfigurationen für Ihre Anwendung unbedingt Versionskontrollen an.

Inkrementelle Entwicklung: Beim Arbeiten mit kleinen Iterationen – Aufbrechen von Features in kleinere Teilfeatures, die jeweils eindeutige Feature-Flags verwenden – lassen sich Probleme leichter isolieren. Außerdem lässt sich das Risiko von Integrationsproblemen verringern, wenn das Feature in die Produktion geht.

Bei der Implementierung eines CI/CD-Prozesses gilt es einige Dinge zu berücksichtigen. In erster Linie gilt es zu verstehen, dass CI/CD ein Workflow und ein Verteilungsprozess und kein Produkt ist. Vermeiden Sie es also, sich in Vorstellungen vom „richtigen CI/CD-Tool“ zu verlieren. Für das Ergebnis, das Sie sich von einem CI/CD-Prozess erhoffen, wird Ihre Softwareentwicklung von einem manuellen, schwerfälligen und langsamen Prozess in einen automatisierten, schlanken und schnellen CI/CD-Prozess umgewandelt.

Sie legen einen Startpunkt fest und stellen dann eine Gruppe aus unterschiedlichen enthusiastischen Entwicklern und Mitarbeitern aus dem operativen Geschäft zusammen, um zunächst einen Proof-of-Concept zu erreichen und dann weiter zu iterieren, bis Ihre CI/CD-Pipeline steht.

Erfolgsorientierte Planung: Von Anfang an ist bei der Implementierung von CI/CD-Prozessen eine Menge technischer Planung erforderlich, einschließlich der Auswahl von Plattformen und der Überarbeitung von Anwendungen, um sie für iterative Aktualisierungen geeigneter zu machen. Aber es wird auch Veränderungen in der Unternehmenskultur geben müssen, wenn sich die Implementierung eines CI/CD-Prozesses über die anfänglichen Enthusiasten hinaus in die Breite des Unternehmens ausweitet. Die Unterstützung der IT und der Geschäftsleitung ist entscheidend für den langfristigen Erfolg von CI/CD.

Optimieren Ihrer Prozesse: Bevor Sie mit der Einführung von CI/CD-Tools in Ihre bestehende Verteilungs-Pipeline beginnen, nehmen Sie sich etwas Zeit, um Ihre aktuellen Prozesse und Arbeitsabläufe zu bewerten. Wenn sie nicht effektiv sind, ist die Automatisierung mithilfe von CI/CD keine Lösung, die alle Probleme auf magische Weise behebt. Überzeugen Sie sich also davon, dass alles reibungslos funktioniert, bevor Sie sie in die neue CI/CD-Pipeline integrieren.

Schwerpunkt auf fortlaufender Verbesserung: Gehen Sie CI/CD mit der Einstellung an, aus Fehlern lernen und sich ständig verbessern zu wollen. Dazu ist es wichtig, dass Ihre CI/CD-Tools kontinuierliche Kennzahlen bereitstellen, die sich in ein gemeinsames Dashboard integrieren lassen, damit alle Beteiligten den Fortschritt verfolgen und bestimmen können, welche Anpassungen an welcher Stelle vorgenommen werden müssen.

AWS (Amazon Web Services) und GCP (Google Cloud Platform) sind zwei beliebte DaaS-Optionen (DevOps-as-a-Service). Beide haben spezielle Vor- und Nachteile für den Aufbau von CI/CD.

AWS ist in der Regel schnell, bietet eine einfache Möglichkeit, Ihren DevOps-Ansatz 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.

Bei der Suche nach CI/CD-Tools, die Sie Ihrer Entwicklungs-Toolchain hinzufügen können, gilt es einige Dinge zu beachten: Zunächst steht die Frage im Raum, ob Sie lieber ein CI/CD-Tool als Open-Source-Lösung im Gegensatz zu einem kommerziellen CI/CD-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 CI/CD-Entwickler den Code drastisch verändern oder die Entwicklung des Produkts ganz einstellen. Außerdem wird für CI/CD-Tools auf Open-Source-Basis oftmals nur minimaler Support geboten. Kommerzielle CI/CD-Tools bieten hingegen in der Regel einen starken Support und vorhersehbarere Update-Zyklen, können aber auch kostspielig sein und eine weniger flexible Integration bieten.

Wenn Sie Ihre eigene CI/CD-Lösung entwickeln, können Sie diese 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 CI/CD-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 CI/CD-Tool auf Open-Source-Basis entstehen Ihnen Kosten für die Einrichtung und den Support des CI/CD-Tools in Ihrer Infrastruktur sowie ein gewisser Produktivitätsverlust, solange die CI/CD-Entwickler lernen, damit umzugehen. Bei kommerziellen Standard- und SaaS-Tools zahlen Sie in der Regel eine Gebühr, die sich nach Ihrem Nutzungsverhalten richtet. elche 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 CI/CD-Tool zugreifen sollen.

Die Geschwindigkeit, mit der Sie Software bereitstellen, stellt am Markt ein wichtiges Unterscheidungsmerkmal dar. Erfolgreiche Unternehmen rühmen sich ihrer 50 bis 100 Bereitstellungen pro Tag, wobei einige Giganten wie Netflix die 1.000er Marke problemlos überschreiten.

Eine funktionierende CI/CD-Pipeline sorgt für die Produktivität, Zuverlässigkeit und Geschwindigkeit, die erforderlich ist, um diese Zahlen zu erreichen und die robusten Anwendungen zu liefern, die es braucht, um mit den sich ständig ändernden geschäftlichen Anforderungen Schritt zu halten. Einfach ausgedrückt: Wenn Sie keine CI/CD-Verfahren anwenden, besteht die Gefahr, dass Ihr Unternehmen ins Hintertreffen gerät. Die Umstellung Ihrer Softwareverteilung ist weder schnell vollzogen noch einfach, aber der Aufwand lohnt sich und wird Ihr Unternehmen für die Zukunft wappnen.