Was ist Continuous Integration/Continuous Delivery (CI/CD)?

Ein wesentliches Merkmal der CI/CD-Pipeline ist der Einsatz von Automatisierung zur Sicherstellung der Codequalität. Während die Softwareänderungen die Pipeline durchlaufen, erkennen automatisierte Tests Abhängigkeiten und andere Probleme bereits in einem frühen Stadium, übertragen Codeänderungen in verschiedene Umgebungen und stellen Anwendungen in Produktionsumgebungen bereit.

Hier besteht die Rolle der Automatisierung darin, die Qualitätskontrolle durchzuführen und alles zu bewerten, von der Leistung über die Nutzung der Anwendungsprogrammierschnittstelle (API) bis hin zur Sicherheit. Dieser Prozess trägt dazu bei, dass die von allen Teammitgliedern vorgenommenen Änderungen umfassend integriert und wie beabsichtigt umgesetzt werden.

Die Möglichkeit, verschiedene Phasen der CI/CD-Pipeline zu automatisieren, hilft Entwicklungsteams dabei, die Qualität zu steigern, schneller zu arbeiten und andere DevOps-Metriken zu verbessern.

Während sich der Begriff „CI/CD-Pipeline“ auf agile DevOps-Workflows bezieht, steht „CI/CD“ für die kombinierten Verfahren der kontinuierlichen Integration und der kontinuierlichen Bereitstellung.

CI/CD bietet eine schnellere und präzisere Methode, die Arbeit verschiedener Personen zu einem einheitlichen Produkt zusammenzuführen. In DevOps-Umgebungen optimiert CI/CD die Codierung, das Testen und die Bereitstellung von Anwendungen. Dieser Ansatz bietet Teams ein zentrales Repository zum Speichern ihrer Arbeit sowie Automatisierung zum Kombinieren und Testen des Codes, um eine konsistente Funktionsweise zu gewährleisten.

Die CI/CD-Pipeline ermöglicht es DevOps-Teams, Code zu schreiben, ihn zu integrieren, Tests durchzuführen, Releases bereitzustellen und Änderungen an der Software gemeinsam und in Echtzeit zu implementieren. Zwar stellt die Automatisierung von Software-Releases – von den ersten Tests bis zur endgültigen Bereitstellung – einen wesentlichen Vorteil der CI/CD-Pipeline dar, doch gibt es noch weitere Vorteile:

• Verkürzte Einsatzzeit: Automatisiertes Testen macht den Entwicklungsprozess effizienter und verkürzt die Dauer des Softwarelieferprozesses. Darüber hinaus ermöglichen die kontinuierliche Bereitstellung und die automatische Bereitstellung, dass die Änderungen eines Entwicklers an einer Cloud-Anwendung innerhalb weniger Minuten nach ihrer Erstellung live geschaltet werden.

• Reduzierte Kosten: Schnelle Entwicklung, Tests und Produktion (ermöglicht durch Automatisierung) bedeuten weniger Entwicklungszeit. Dieser Prozess Ergebnisse in geringeren Kosten im Vergleich zur traditionellen Softwareentwicklung.

• Kontinuierliche Feedbackschleifen: Die CI/CD-Pipeline stellt einen kontinuierlichen Zyklus dar: bauen, testen, bereitstellen. Feedbackschleifen ermöglichen es Entwicklern, schnell zu reagieren und den Code nach jedem Test zu verbessern.

• Frühe Fehlererkennung: Bei der kontinuierlichen Integration wird für jede erstellte Codeversion ein automatisierter Test durchgeführt, um Integrationsprobleme zu erkennen. Diese Probleme lassen sich leichter Fixes, je früher sie in der Pipeline auftreten.

• Geringere Ausfallzeiten und höhere Zuverlässigkeit: Im Falle von Fehlern bei der Bereitstellung, Programmfehlern oder Leistungsproblemen sorgen Funktionen wie automatisierte Rollbacks dafür, dass ein Softwaresystem oder eine App in einen früheren stabilen Zustand zurückversetzt wird. Diese Funktion minimiert Ausfallzeit und erhöht die Zuverlässigkeit des Services.

• Verbesserte Teamzusammenarbeit und Systemintegration: Alle Teammitglieder können Code ändern, auf Feedback reagieren und schnell auf etwaige Probleme reagieren.

Die CI/CD-Pipeline besteht aus drei miteinander verbundenen Methoden:

• Kontinuierliche Integration
• Continuous Delivery
• Kontinuierliche Bereitstellung

Der CI/CD-Prozess beginnt mit der kontinuierlichen Integration (CI), bei der Entwickler ihren Code in zentrale Repositories eintragen, die von Versionskontrollsystemen (VCS) verwaltet werden. CI ermöglicht es Entwicklern, unabhängig zu arbeiten und ihren eigenen Codierung- „Branch“ zu erstellen, um kleine Änderungen umzusetzen.

Während der Entwickler arbeitet, kann er Snapshots des Quellcodes erstellen, typischerweise innerhalb eines Versionierungstools wie Git. Der Entwickler kann sich dann ungestört neuen Funktionen widmen; falls ein Problem auftritt, kann Git die Codebasis schnell auf ihren vorherigen Zustand zurücksetzen.

Die Arbeit einzelner Personen wird dann in ein automatisiertes System übertragen, das Skripte verwendet, um die Codeänderungen zu erstellen und zu testen. Nach der automatisierten Build-Phase kompiliert ein CI-Server die Quellcode-Änderungen in den Hauptzweigcode oder den „Stamm“ des gemeinsamen Quellcode-Repositorys.

Anstatt Code unabhängig voneinander zu schreiben und ihn einmal im Monat in den Hauptzweig abzusenden, was zu aufwendiger Fehlerbehebung und schlechter Versionskontrolle führen kann, ermöglicht der CI/CD-Entwicklungsprozess den Teams, Codeänderungen häufiger abzusenden. Dieses kontinuierliche Testen ermöglicht schnellere Fixes, sorgt für die Funktionalität und führt letztlich zu besserer Zusammenarbeit und Softwarequalität.

Der nächste Schritt in der Pipeline ist Continuous Delivery (CD), bei dem die validierten Codeänderungen, die im Rahmen der kontinuierlichen Integration vorgenommen wurden, in ausgewählte Umgebungen oder Code-Repositorys wie GitHub übertragen werden. Hier kann das Betriebsteam diese in einer Live-Produktionsumgebung bereitstellen.

Die Software und die APIs werden getestet, und Fehler werden im Rahmen eines automatisierten Prozesses behoben. Im letzten Schritt des CD-Prozesses erhält das DevOps-Team eine Benachrichtigung über den neuesten Build und leitet diesen manuell an die Bereitstellungsphase weiter.

Das Ziel der Phase der Continuous Delivery Pipeline ist es, neuen Code mit minimalem Aufwand bereitzustellen, aber dennoch ein gewisses Maß an menschlicher Kontrolle zu ermöglichen.

Die CD im CI/CD-Prozess steht auch für kontinuierliche Bereitstellung. Bei der kontinuierlichen Bereitstellung werden Codeänderungen automatisch an Endbenutzer freigegeben, nachdem eine Reihe vordefinierter Tests bestanden wurde, beispielsweise Integrationstests, bei denen der Code in einer Umgebung getestet wird, um die Integrität sicherzustellen.

Sowohl Continuous Delivery als auch Continuous Bereitstellung befassen sich mit der Automatisierung weiter unten in der Pipeline als CI und werden oft austauschbar verwendet.

Der Unterschied zwischen Continuous Delivery und Continuous Deployment liegt im Grad der Automatisierung, der in Software- oder App-Veröffentlichungen verwendet wird. Bei der kontinuierlichen Bereitstellung wird der Code automatisch in produktionsähnliche Umgebungen verschoben, um weitere Tests und die Qualitätssicherung durchzuführen, z. B. die Bewertung von Risiken und die Identifizierung von Schwachstellen im Quellcode. Nach erfolgreichen Tests ist menschliches Eingreifen erforderlich, um in die Produktion übergehen zu können.

In der kontinuierlichen Bereitstellung geht die Automatisierung noch weiter. Sobald der Code die Tests bestanden hat, erfolgt die Bereitstellung in der Produktion automatisch – eine menschliche Genehmigung ist nicht erforderlich.

Inwieweit ein Unternehmen die CI/CD-Pipeline einsetzt und ob es sich für Continuous Delivery oder Continuous Deployment entscheidet, hängt von seinen geschäftlichen Anforderungen ab. Die kontinuierliche Bereitstellung eignet sich am besten für DevOps-Teams mit einem schnellen Entwicklungszyklus, wie beispielsweise Teams, die E-Commerce-Websites und Software-as-a-Service (SaaS)-Plattformen entwickeln.

Continuous Deployment unterstützt den Software-Release-Prozess, indem es Teams ermöglicht, neue oder aktualisierte Software häufig und so schnell wie möglich bereitzustellen. Da Änderungen automatisch in die öffentliche Umgebung bereitgestellt werden, wird diese Art von Continuous-Deployment-Pipeline in der Regel nur von DevOps-Teams genutzt, die über einen bewährten Prozess verfügen.

Für Teams, die Updates in ihrem Workflow möglicherweise nicht so häufig veröffentlichen müssen – wie etwa bei der Entwicklung von Gesundheitsanwendungen – ist Continuous Delivery in der Regel die bevorzugte Option. Es ist zwar langsamer, bietet aber eine zusätzliche Kontrollebene, um die Funktionalität für die Endbenutzer sicherzustellen.

Um den Unterschied zwischen Continuous Delivery und Continuous Bereitstellung genauer zu verstehen, sehen Sie sich dieses Video an.

Eine Pipeline für maschinelles Lernen ist eine Reihe miteinander verbundener Datenverarbeitungs- und Modellierungsschritte, die entwickelt wurden, um den Prozess der Erstellung, Schulung, Bewertung und Bereitstellung von maschinellen Lernmodellen zu automatisieren, zu standardisieren und zu optimieren.

Maschinelles Lernen Pipelines sind eine wesentliche Komponente der Entwicklung und Produktion von maschinellen Lernsystemen (ML). Darüber hinaus sind sie aufgrund des Wachstums von Big Data und künstlicher Intelligenz (KI) immer wichtiger geworden.

Laut Kings Forschung wurde der globale Markt für maschinelles Lernen im Jahr 2023 auf 26,06 Milliarden US-Dollar geschätzt und soll von 35,44 Milliarden US-Dollar im Jahr 2024 auf 328,89 Milliarden US-Dollar im Jahr 2031 anwachsen, was einer durchschnittlichen jährlichen Wachstumsrate (CAGR) von 37,47 % während des Forecasting entspricht.¹

Pipelines für maschinelles Lernen lassen sich in DevOps-Praktiken integrieren, um CI/CD von Modellen für maschinelles Lernen zu ermöglichen. Diese Integration wird als Machine Learning Operations (MLOps) bezeichnet und hilft Data-Science-Teams dabei, die Komplexität der Verwaltung der ML-Orchestrierung effektiv zu bewältigen.

Vom Quellcode bis zur Produktion umfassen diese Phasen den Entwicklungslebenszyklus und den Workflow der CI/CD-Pipeline:

• Erstellen
• Test
• Bieten
• Bereitstellung

Diese Phase ist Teil des Continuous-Integration-Prozesses und umfasst die Erstellung und Kompilierung von Code. Die Teams arbeiten gemeinsam auf der Grundlage des Quellcodes und integrieren neuen Code, wobei sie eventuelle Probleme oder Konflikte umgehend erkennen.

In dieser Phase testen die Teams den Code. Automatisierte Tests finden sowohl im Rahmen der kontinuierlichen Bereitstellung als auch der kontinuierlichen Implementierung statt. Diese Testumgebungen können Integration, Unit-Tests und Regression umfassen.

Hier wird eine freigegebene Codebasis in eine Produktionsumgebung gesendet. Dieser Schritt ist bei Continuous Bereitstellung automatisiert und wird bei Continuous Delivery erst nach Genehmigung durch den Entwickler automatisiert.

Schließlich werden die Änderungen umgesetzt und das Endprodukt wird in die Produktion überführt. Bei der kontinuierlichen Lieferung werden Produkte oder Code an Repositories gesendet und durch menschliche Genehmigung in Produktion oder Bereitstellung verschieben. Bei der kontinuierlichen Bereitstellung ist dieser Schritt automatisiert.

Bei der Auswahl von CI/CD-Tools sollte der Schwerpunkt auf der Optimierung und Automatisierung des Softwareentwicklungsprozesses liegen. Eine effektive CI/CD-Pipeline nutzt Open Source Tools für Integration Testing und Bereitstellung. Die korrekte Konfiguration Ihres CI/CD-Prozesses wirkt sich ebenfalls auf den Erfolg der Softwareentwicklungs-Pipeline aus.

Das am weitesten verbreitete Open-Source-CI/CD-Tool ist Jenkins. Jenkins ist ein automatisierter CI-Server, der in Java geschrieben ist und zur Automatisierung von CI/CD-Schritten und Berichten verwendet wird. Zu den weiteren Open-Source-Tools für die Integration gehören Travis CI und CircleCI.

Neben Open Source Tools bieten alle großen Cloud-Service-Anbieter – Google Cloud, IBM® Cloud, Microsoft Azure und Amazon Web Services (AWS) – cloudbasierte CI/CD-Toolchains, Pipelines und Integrationen an.

Integrierte Entwicklungsumgebungen (IDE) wie GitHub oder AWS CodeCommit unterstützen Entwickler bei der Erstellung, Pflege und Nachverfolgung von Softwarepaketen. Gleichzeitig sind Plattformen wie GitLab bestrebt, die IDE als Teil einer umfassenden Plattform anzubieten, die auch andere Tools umfasst.

Wenn in einer Cloud-Umgebung operiert wird, verwenden cloudnative DevOps-Teams Container wie Docker für die Verpackung und den Versand von Anwendungen und verwenden Container-Orchestrierungstools wie Kubernetes. Kubernetes ist zwar nicht ausschließlich für die CI/CD-Pipeline vorgesehen, wird aber in vielen CI/CD-Workflows verwendet.

CI/CD-Sicherheit konzentriert sich auf Praktiken, Prozesse und Technologien, die Sicherheits- und Compliance-Maßnahmen entlang der gesamten CI/CD-Pipeline implementieren und verwalten.

Früher wurde Sicherheit erst am Ende des Entwicklungszyklus „hinzugefügt“. Die Weiterentwicklung von Cloud-Plattform, Microservice und Container hat einen Engpass für den traditionellen Entwicklungsansatz geschaffen.

Die Sicherheit könnte mit den schnellen Releases nicht Schritt halten, da Entwickler flexible und DevOps-Praktiken eingeführt haben, was die Entwicklung von DevSecOps, das für Entwicklung, Sicherheit und Betrieb steht, vorangetrieben hat. DevSecOps automatisiert die Integration von Sicherheitstool-Praktiken, sobald diese innerhalb von Continuous Integration (CI)- und Continuous Delivery (CD)-Pipelines auftauchen.

DevSecOps-Praktiken umfassten Shift-Left- und Shift-Right-Tests. Shift-Left-Testing beinhaltet die Integration von Sicherheitstests und anderen wichtigen Entwicklungspraktiken früher im Softwareentwicklungszyklus (SDLC). Beim Shift-Right-Testing werden Tests später im Entwicklungsprozess durchgeführt, üblicherweise in Produktionsumgebungen. Diese Methoden ergänzen sich gegenseitig, indem sie die Testverantwortung auf das gesamte SDLC verteilen.