Was ist CI/CD? Konzepte und CI/CD Tools im Überblick

CI/CD (Continuous Integration/Continuous Delivery) sind bewährte DevOps-Methoden zur Automatisierung in der Anwendungsentwicklung. Die Hauptkonzepte von CI/CD sind Continuous Integration (kontinuierliche Integration), Continuous Delivery und Continuous Deployment (kontinuierliche Verteilung).

CI/CD automatisiert alle Phasen der Anwendungsentwicklung und stellt Kunden neue Apps kontinuierlich bereit. Dadurch werden Probleme, die bei der Integration von neuem Code für DevOps-Teams auftreten (auch bekannt als die „Integrationshölle") gelöst und eine schnelle, konsistente Anwendungsentwicklung unterstützt. 

Insbesondere sorgt CI/CD für eine kontinuierliche Automatisierung und Überwachung über alle Phasen des Application Lifecycles hinweg, von Integration und Tests bis hin zu Bereitstellung und Deployment. Diese zusammenhängenden Praktiken werden oft als „CI/CD-Pipeline" bezeichnet. Sie werden von Entwicklungs- und Operations-Teams unterstützt, die auf agile Weise mit einem DevOps- oder SRE-Ansatz (Site Reliability Engineering) zusammenarbeiten.

Die Abkürzung CI/CD hat unterschiedliche Bedeutungen. „CI" in CI/CD bedeutet Continuous Integration, also der Automatisierungsprozess für Entwicklungsteams. Bei einer erfolgreichen CI werden regelmäßig neue Codeänderungen für Apps entwickelt, geprüft und in einem gemeinsamen Repository zusammengeführt. Damit soll der Konflikt verhindert werden, den zu viele Verzweigungen einer App verursachen können, wenn sie zeitgleich entwickelt werden.

„CD" in CI/CD bedeutet Continuous Delivery bzw. Continuous Deployment. Das sind verwandte Konzepte, die zuweilen synonym verwendet werden. Obwohl es bei beiden Konzepten um die Automatisierung weiterer Phasen der Pipeline geht, werden die Begriffe manchmal unterschiedlich verwendet, um das Ausmaß der Automatisierung zu verdeutlichen.

Continuous Delivery bedeutet üblicherweise, dass App-Änderungen eines Entwicklers automatisch auf Bugs getestet und in ein Repository (wie GitHub oder eine Container-Registry) hochgeladen werden, von wo aus sie vom Operations-Team in einer Live-Produktivumgebung bereitgestellt werden können. Auf diese Weise können Transparenz- und Kommunikationsprobleme zwischen Dev- und Business-Teams schneller gelöst werden. Mit Continuous Delivery soll also sichergestellt werden, dass neuer Code mit minimalem Aufwand bereitgestellt werden kann.

Continuous Deployment bezieht sich auf die automatische Freigabe von Entwickleränderungen vom Repository zur Produktivphase, wo sie direkt vom Kunden genutzt werden können. Dieser Vorgang soll der Überlastung von Operations-Teams bei manuellen Prozessen entgegenwirken, die die Anwendungsbereitstellung verlangsamen. Continuous Deployment baut die Vorteile der Continuous Delivery aus, indem auch noch die nächste Phase der Pipeline automatisiert wird.

Manchmal sind mit CI/CD lediglich die zusammenhängenden Praktiken der Continuous Integration und der Continuous Delivery, manchmal aber auch alle drei Konzepte der Continuous Integration, der Continuous Delivery und des Continuous Deployments gemeint. Noch komplizierter wird das Ganze dadurch, dass mit „Continuous Delivery" zuweilen auch die Prozesse des Continuous Deployments mitgemeint sind.

Letztendlich bringen uns diese Details jedoch nicht weiter. Sehen Sie CI/CD einfach als Prozess an, der nicht selten als Pipeline visualisiert wird und der ein hohes Maß an kontinuierlicher Automatisierung und Überwachung bei der Anwendungsentwicklung umfasst.

Je nach Fall hängt die Auslegung des Begriffs vom Grad der Automatisierung der CI/CD-Pipeline ab. Viele Unternehmen arbeiten zunächst mit CI und setzen den Prozess später mit der automatischen Bereitstellung und dem automatischen Deployment fort, wie etwa bei cloudnativen Anwendungen.

Bei der modernen Anwendungsentwicklung arbeiten mehrere Entwicklerinnen und Entwickler an unterschiedlichen Features einer Anwendung. Die gleichzeitige Zusammenführung aller Quellcode-Verzweigungen an einem Tag (auch bekannt als „Merge Day") kann einen hohen Arbeits- und Zeitaufwand bedeuten. Der Grund dafür ist, dass Anwendungsänderungen von getrennt arbeitenden Entwicklerinnen und Entwicklern miteinander in Konflikt treten können, wenn sie zeitgleich durchgeführt werden. Dieses Problem kann sich verschlimmern, wenn jede Entwicklerin bzw. jeder Entwickler seine eigene lokale Integrated Development Environment (IDE) definiert, statt im Team eine gemeinsame cloudbasierte IDE zu erstellen.

Mithilfe der Continuous Integration (CI) können Entwicklungsteams ihre Codeänderungen in einer gemeinsamen „Verzweigung" oder „Trunk" der Anwendung viel häufiger zusammenführen, manchmal sogar täglich. Sobald die Änderungen eines Mitglieds des Entwicklungsteams zusammengeführt wurden, werden sie in automatischen App-Builds und unterschiedlichen Stufen von Automatisierungsprüfungen (normalerweise Einheits- und Integrationstests) validiert. So wird sichergestellt, dass die Funktionsfähigkeit nicht beeinträchtigt wurde. Dabei müssen alle Klassen und Funktionen bis hin zu den verschiedenen Modulen der App getestet werden. Wenn die automatische Prüfung Konflikte zwischen aktuellem und neuem Code erkennt, lassen sich diese mithilfe von CI schneller und häufiger beheben.

Nach der Automatisierung von Builds und Einheits- und Integrationstests bei der CI wird bei der Continuous Delivery auch die Freigabe des validierten Codes an ein Repository automatisch durchgeführt. Um also für einen effizienten Continuous Delivery-Prozess zu sorgen, muss die CI bereits in Ihre Entwicklungs-Pipeline integriert sein. Ziel der Continuous Delivery ist eine Codebasis, die jederzeit in einer Produktivumgebung bereitgestellt werden kann.

Bei der Continuous Delivery umfasst jede Phase − von der Zusammenführung der Codeänderungen bis zur Bereitstellung produktionsreifer Builds − automatisierte Tests und Codefreigaben. Am Ende dieses Prozesses kann das Operations-Team eine App schnell und einfach in der Produktivphase bereitstellen.

Die abschließende Phase der CI/CD-Pipeline ist das Continuous Deployment. Als Erweiterung der Continuous Delivery, bei der produktionsreife Builds automatisch an ein Code-Repository freigegeben werden, wird beim Continuous Deployment auch die Freigabe einer App in die Produktivphase automatisiert. Da der Produktivphase in der Pipeline kein manuelles Gate vorgeschaltet ist, müssen beim Continuous Deployment die automatisierten Tests immer sehr gut durchdacht sein.

In der Praxis bedeutet Continuous Deployment, dass App-Änderungen einer Entwicklerin oder eines Entwicklers binnen weniger Minuten nach ihrer Erstellung live gehen können (vorausgesetzt, sie bestehen den automatischen Test). Dies erleichtert eine kontinuierliche Integration von Benutzerfeedback ungemein. All diese zusammenhängenden CI/CD-Praktiken machen das Deployment einer Anwendung weniger riskant, weil Änderungen in Teilen und nicht auf einmal freigegeben werden. Die Vorabinvestitionen sind allerdings beträchtlich, da automatische Tests für die diversen Prüf- und Release-Phasen in der CI/CD-Pipeline geschrieben werden müssen.

CI/CD-Tools können ein Team dabei unterstützen, die Entwicklung, das Deployment und die Tests zu automatisieren. Einige Tools unterstützen speziell die Integration (CI), andere verwalten die Entwicklung und das Deployment (CD), andere wiederum kontinuierliches Testen oder ähnliche Funktionen.

Eines der bekanntesten Open Source-Tools für CI/CD ist der Automatisierungsserver Jenkins. Jenkins kann alles verarbeiten – vom einfachen CI-Server bis hin zum kompletten CD-Hub.

Deployment von Jenkins auf Red Hat OpenShift

Tekton Pipelines ist ein CI/CD-Framework für Kubernetes-Plattformen, das eine cloudnative CI/CD-Standarderfahrung mit Containern ermöglicht. OpenShift Pipelines ist eine Funktion von Red Hat OpenShift, die auf Tekton aufbaut. 

Tekton and cloudnative CI/CD in Red Hat OpenShift

Neben Jenkins und Tekton Pipelines gibt es noch weitere quelloffene CI/CD-Tools, die Sie sich ansehen sollten:

• Spinnaker, eine CD-Plattform, die für Multi-Cloud-Umgebungen entwickelt wurde.
• GoCD, ein CI/CD-Server mit Schwerpunkt auf Modellierung und Visualisierung.
• Concourse, „ein kontinuierlicher Open Source-Macher".
• Screwdriver, eine für CD konzipierte Build-Plattform.

Teams können auch gemanagte CI/CD-Tools in Betracht ziehen, die von verschiedenen Anbietern erhältlich sind. Die großen Public Cloud-Anbieter verfügen alle über CI/CD-Lösungen, ebenso wie GitLab, CircleCI, Travis CI, Atlassian Bamboo und viele andere.

Außerdem ist ein Tool, das für DevOps grundlegend ist, wahrscheinlich auch Teil eines CI/CD-Prozesses. Tools für die Konfigurationsautomatisierung (wie Ansible, Chef und Puppet), Container Runtimes (wie Docker, rkt und cri-o) und Container-Orchestrierung (Kubernetes) sind keine reinen CI/CD-Tools, kommen aber in vielen CI/CD-Workflows vor.

Es gibt viele verschiedene Möglichkeiten, CI/CD zu implementieren, je nach der von Ihnen bevorzugten Strategie für die Anwendungsentwicklung und dem Cloud-Anbieter. Red Hat® OpenShift® Service on AWS bietet verschiedene Optionen wie z. B. Tekton und OpenShift Pipelines, um Ihren eigenen CI/CD-Workflow zu vereinfachen. Durch den Einsatz von Red Hat OpenShift können Unternehmen CI/CD einsetzen, um die Entwicklung, das Testen und das Deployment einer Anwendung auf mehreren On-Premise und Cloud-Plattformen zu automatisieren.