Was ist eine CI/CD-Pipeline?

Continuous Integration (CI)

Continuous Integration (CI) ist eine Praxis in der Softwareentwicklung, bei der die Entwickler ihre Codeänderungen regelmäßig in ein zentrales Repository einspeisen. Nach jeder Aktualisierung sorgen automatisierte Build- und Testprozesse dafür, dass der neue Code aller Entwickler in die bestehende Codebasis integriert wird – ohne dass dabei Fehler entstehen. Dadurch minimiert CI die von älteren Ansätzen bekannten Probleme bei der Zusammenführung von Änderungen am Ende des Entwicklungszyklus.

Continuous Delivery and Deployment (CD)

Continuous Delivery und Continuous Deployment (beide mit „CD“ abgekürzt) umfassen die Etappen nach der CI. Continuous Delivery automatisiert die Veröffentlichung und sorgt dafür, dass jede Version der Software jederzeit in einer Produktionsumgebung bereitgestellt werden kann. Die Software ist trotz der ständigen Änderungen jederzeit in einem implementierbaren Zustand. Continuous Deployment geht noch einen Schritt weiter und implementiert jede Änderung, die die automatisierten Tests besteht, automatisch, wodurch die Vorlaufzeit erheblich verkürzt wird.

Bei beiden Verfahren wird die Anwendung mithilfe vordefinierter Infrastrukturkonfigurationen automatisch in verschiedenen Umgebungen, etwa Vorbereitungs- und Produktionsumgebungen, bereitgestellt. Die CD-Pipeline beinhaltet auch zusätzliche Tests, z. B. Integrations-, Leistungs- und Sicherheitsprüfungen, um die Qualität und Zuverlässigkeit der Anwendung sicherzustellen.

Abgrenzung: Continuous Delivery und Continuous Deployment

Der Hauptunterschied zwischen Continuous Delivery und Continuous Deployment liegt im letzten Schritt der Überführung von Änderungen in die Produktion. Bei Continuous Delivery wird der letzte Bereitstellungsschritt manuell durchgeführt. Dies bietet zusätzliche Sicherheit, da mögliche Probleme, die bei den automatisierten Tests nicht aufgefallen sind, an diesem Punkt noch bemerkt werden können. Im Gegensatz dazu ist bei Continuous Deployment die gesamte Pipeline automatisiert, einschließlich der Bereitstellung in der Produktion. Sie erfordert daher strenge Tests und eine genaue Überwachung, damit Probleme erkannt und behoben werden können.

CI/CD steht also für die beiden folgenden Ansätze:

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

Mit einer CI/CD-Pipeline sind eine schnellere Markteinführung, kontinuierliche Feedbackschleifen und eine bessere Softwarequalität erreichbar. CI/CD fördert die Zusammenarbeit zwischen Entwickler-, Betriebs- und Sicherheitsteams und somit die Bereitstellung sicherer, stabiler und hochleistungsfähiger Anwendungen.

So funktioniert CI/CD: ein Tag im Leben der Pipeline

Der Tag der CI/CD-Pipeline beginnt damit, dass ein Entwickler seinen ersten Becher Kaffee trinkt. Während er sich an seinem Arbeitsplatz einrichtet, zieht er sich den aktuellen Code aus dem Versionskontrollsystem, Git. Mit den neuesten Änderungen vor sich macht der Entwickler sich dann an die Arbeit – entwickelt neue Funktionen und behebt Fehler.

Anschließend sendet er seine Änderungen an ein gemeinsames Repository. Dieser auch als „Commit“ bezeichnete Vorgang startet die CI/CD-Pipeline. Die mit Webhooks konfigurierte Pipeline erkennt das Commit und leitet ein „Build“ ein. Dabei übersetzt die Pipeline den Quellcode mit einem Tool wie Jenkins oder CircleCI in eine ausführbare Datei. Bei einer Java-Anwendung könnte hingegen ein Maven- oder Gradle-Build ausgeführt werden.

Als Nächstes verpackt die Pipeline die Anwendung in einem implementierbaren Artefakt. Für eine Webanwendung könnte das beispielsweise ein Docker-Image sein. Die Pipeline leitet dieses Image dann an eine Docker-Registry, z. B. Docker Hub, oder an eine private, auf AWS ECR oder Google Container Registry gehostete Registry weiter.

Wenn der Build abgeschlossen ist, geht die Pipeline zur Testphase über und startet eine Testumgebung, oft unter Verwendung eines Tools für die Containerorchestrierung wie Kubernetes. Sie implementiert die Anwendung in dieser Umgebung und führt eine Suite automatisierter Tests aus. Die Suite könnte zum Beispiel von JUnit ausgeführte Komponententests, von einem Tool wie Postman ausgeführte Integrationstests und von Selenium ausgeführte End-to-End-Tests beinhalten.

Wenn alle Tests bestanden werden, folgt als Nächstes in der Pipeline die Bereitstellungsphase, während der die Testumgebung abgebaut und eine Produktionsumgebung eingerichtet wird. Daraufhin implementiert die Pipeline die Anwendung in dieser Umgebung, wobei oft eine Blue/Green-Bereitstellungsstrategie genutzt wird, um Ausfallzeiten zu vermeiden und die Änderungen bei Bedarf schnell rückgängig zu machen.

Den ganzen Tag lang durchläuft die Pipeline diesen Prozess für jedes neue Commit. Darüber hinaus erledigt sie Aufgaben wie die Abwicklung von Datenbankmigrationen mit Tools wie Flyway oder Liquibase, die Ausführung statischer Codeanalysen mit SonarQube und sogar die automatische Skalierung der Produktionsumgebung auf Basis von Datenverkehrsmustern.

Außerdem erhält das Entwicklerteam in Echtzeit Feedback von der Pipeline. Sie sendet Benachrichtigungen über Build-Ergebnisse an einen Slack-Kanal, erstellt in Jira Tickets für fehlgeschlagene Builds und aktualisiert in Echtzeit ein Dashboard mit Kennzahlen zur Leistung der Pipeline.

Am Ende des Tages ist die CI/CD-Pipeline bereit für das nächste Commit und die nächste Runde ihrer Mission, in schnellem Tempo hochwertige Software bereitzustellen. Der Tag der Pipeline mag eintönig sein, aber jede Wiederholung bringt das Team seinem Ziel näher, den Benutzern einen Mehrwert zu bieten.

Die Etappen einer CI/CD-Pipeline

Als technologiegetriebener Prozess ist CI/CD mit Versionskontrollsystemen, Build-Servern und anderen Entwicklungstools verknüpft. Die Standardpipeline besteht aus mehreren Etappen, die den Code unter verschiedenen Gesichtspunkten prüfen, um zu ermitteln, ob er ohne Bedenken bereitgestellt werden kann.

Wenn ein Entwickler Code an das Versionskontrollrepository schickt, übernimmt die Pipeline und führt automatisch die Quellcode-, Build-, Test- und Bereitstellungsphase aus.

Quellcodephase

In der Quellcodephase laden die Entwickler ihre Codeänderungen mit einem Commit in das Versionskontrollsystem. Die CI/CD-Pipeline überwacht das Repository und leitet die nächste Phase ein, wenn ein neues Commit erkannt wird. Gängige Versionskontrollsysteme sind Git, Mercurial und Subversion.

Build-Phase

In der Build-Phase kompiliert die CI/CD-Pipeline den Quellcode und erstellt ausführbare Artefakte. Während der Build-Phase kann der Code zudem in einem Docker-Container oder einem anderen für die Bereitstellung geeigneten Format verpackt werden. Für eine zuverlässige CI/CD-Pipeline sollte der Build-Prozess wiederholbar und konsistent sein.

Testphase

Während der Testphase werden die erstellten Artefakte einer Reihe automatisierter Tests unterzogen, darunter beispielsweise Komponententests, Integrationstests und End-to-End-Tests. Die automatisierten Tests in dieser Phase sind zur frühen Identifizierung und Behebung etwaiger Probleme unverzichtbar.

Bereitstellungsphase

Die Bereitstellungsphase ist die letzte Phase der CI/CD-Pipeline. Wenn die Pipeline für Continuous Delivery konfiguriert ist, wird das Release in dieser Phase für die manuelle Bereitstellung vorbereitet. Wenn sie für Continuous Deployment konfiguriert ist, stellt die Pipeline das Release automatisch in der Produktionsumgebung bereit.

Arten von CI/CD-Pipelines

Eine CI/CD-Pipeline für ein einfaches Programm umfasst typischerweise eine Quellcode-, Build-, Test- und Bereitstellungsphase. Entwickler laden Code in ein Versionskontrollsystem wie Git. Die Pipeline leitet einen Build-Vorgang ein, bei dem der Code kompiliert und Artefakte erstellt werden. Zur Qualitätssicherung werden diese Artefakte automatisierten Tests unterzogen. Wenn die Tests bestanden werden, stellt die Pipeline die Artefakte in einer Produktionsumgebung bereit. Tools wie Jenkins, CircleCI oder GitLab CI/CD können diesen Prozess koordinieren.

Cloudnative CI/CD-Pipelines

Eine cloudnative CI/CD-Pipeline nutzt die inhärente Modularität von Microservices, um die unabhängige Entwicklung und Bereitstellung einzelner Microservices zu unterstützen. Jeder Microservice verfügt über eine eigene Pipeline, wodurch Tests, Entwicklung und Bereitstellung voneinander isoliert erfolgen. Hierdurch werden das Risiko von Dominoeffekten bei Fehlern reduziert und das Bereitstellungstempo erhöht.

Sicherheit wird in der auf Microservices basierenden Pipeline auf verschiedenen Ebenen durchgesetzt. Unter anderem wird jeder Microservice als eine potenzielle Sicherheitsgrenze mit eigenen Berechtigungen und Kontrollmaßnahmen betrachtet. Durch die Befolgung von Praktiken für die Containersicherheit, wie Image-Scans und Laufzeitschutz, wird die Integrität von Microservices geschützt.

Service-Meshes wie Istio oder Linkerd sind eine gängige cloudnative Pipelinetechnologie, die Mutual-TLS und ähnliche Funktionen für die Service-to-Service-Kommunikation als einheitliche Mittel zum Schützen, Verbinden und Überwachen von Microservices bereitstellt.

Cloudnative CI/CD-Pipelines nutzen cloudbasierte Tools für Code-Repositorys, Build-Server und Bereitstellungsziele. Zum Beispiel nutzt eine Pipeline in AWS möglicherweise CodeCommit zum Laden des Quellcodes, CodeBuild zum Kompilieren und Testen und CodeDeploy zur Bereitstellung. Diese Pipelines können nach Bedarf skaliert werden, mit cloudnativen Funktionen verknüpft werden und bieten einen nutzungsbasierten Tarif.

Kubernetes-native Pipelines

Die erweiterbare Architektur von Kubernetes entspricht den CI/CD-Prinzipien und unterstützt eine schnelle und zuverlässige Bereitstellung. Die Kubernetes-native Pipeline agiert direkt in einem Kubernetes-Cluster, dessen Funktionen sie für die Orchestrierung, Skalierung und Verwaltung containerisierter Anwendungen nutzt. Sie kann containerisierte Anwendungen über mehrere Cluster hinweg bereitstellen, Wiederherstellungen durchführen und die Service-Inventarisierung abwickeln. Die Phasen der Pipeline, darunter Entwicklung, Tests und Bereitstellung, werden als Kubernetes-Jobs oder ‑Pods ausgeführt, wodurch sie isoliert sind und die Ressourcennutzung gesteuert werden kann.

Für die Sicherheit in Kubernetes-nativen Pipelines sind Kubernetes-spezifische Praktiken notwendig. Rollenbasierte Zugriffskontrolle (RBAC) dient dazu, die Berechtigungen für Pipelinephasen zu beschränken, wodurch die Folgen potenzieller Sicherheitsprobleme eingedämmt werden. Sicherheitsrichtlinien für Pods können die Funktionalität der Container, in denen die Pipelinephasen ausgeführt werden, beschränken und so das Sicherheitsniveau stärken.

CI/CD-Tools wie Jenkins X, Tekton und Argo CD, die für Kubernetes-native Pipelines entwickelt wurden, bieten Funktionen wie Umgebungspromotion über GitOps und die Vorschau von Umgebungen für Pull-Anfragen.

CI/CD-Pipeline für ein Monorepo

Ein Monorepo ist ein Repository, das mehr als ein logisches Projekt enthält. Die CI/CD-Pipeline für ein Monorepo muss Änderungen über mehrere Projekte hinweg effizient bearbeiten können. Sie sollte die Build- und Testprozesse nur für die Projekte ausführen, die von einem Commit betroffen sind, nicht für das gesamte Repository.

Entwickler können erweiterte CI/CD-Tools wie Bazel oder Cloud Build von Google nutzen, um ein Abhängigkeitsdiagramm ihrer Codebasis zu erstellen und anschließend zu nutzen, um die Build- und Testprozesse nur für die Teile der Codebasis zu wiederholen, die von dem geänderten Code abhängen.

Sicherheit in einer Monorepo-CI/CD-Pipeline verhindert, dass Änderungen sich auf andere Komponenten auswirken. Durch automatisierte Tests und statische Codeanalysen werden potenzielle Sicherheitsprobleme bereits früh in der Pipeline erkannt. Die Codeüberprüfung muss streng sein, damit die Integrität des Monorepos bewahrt bleibt.

CI/CD in der Cloud

Cloud-Plattformen bieten leistungsstarke Fähigkeiten für die Einrichtung von CI/CD-Pipelines, wie nahezu unbegrenzte Skalierbarkeit, Hochverfügbarkeit und integrierte Mechanismen für die Notfallwiederherstellung.

Die Elastizität von Cloud-Ressourcen unterstützt die dynamische Skalierung von CI/CD-Prozessen entsprechend der Workload und fördert so die Effizienz und Kostenoptimierung. CI/CD in der Cloud unterstützt außerdem verteilte Entwicklerteams, verbessert so deren Zusammenarbeit und ermöglicht einen globalen Ansatz für die Softwareentwicklung.

CI/CD in AWS

Amazon Web Services (AWS) bietet eine Suite von Tools für die Einrichtung einer CI/CD-Pipeline. AWS CodeCommit, ein vollständig verwalteter Service für die Quellcodekontrolle, hostet sichere Git-Repositorys, über die eine Zusammenarbeit bei der Programmierung und Versionskontrolle möglich ist.

AWS CodeBuild, ein verwalteter Build-Service, kompiliert Quellcode, führt Tests durch und erstellt einsatzfertige Softwarepakete. AWS CodePipeline, ein Service für Continuous Integration und Continuous Delivery, koordiniert den Workflow vom Quellcode bis zur Bereitstellung und ermöglicht die Modellierung, Visualisierung und Automatisierung des gesamten Prozesses bis zur Veröffentlichung der Software.

AWS CodeDeploy, ein automatisierter Bereitstellungsservice, unterstützt die Bereitstellung von Anwendungen in verschiedenen AWS-Services wie Amazon EC2, AWS Lambda und Amazon ECS. AWS lässt sich auch mit beliebten Open-Source-Tools verknüpfen, für die es eine flexible und umfassende CI/CD-Lösung bereitstellt.

CI/CD in Azure

Azure Pipelines ist ein Cloud-Service, der sowohl Continuous Integration als auch Continuous Delivery unterstützt und mit jeder Sprache und Plattform kompatibel ist. Damit stellt er eine vielseitige Lösung für verschiedenste Entwicklungsumgebungen bereit.

Azure Repos bietet unbegrenzte, in der Cloud gehostete private Git-Repositorys, über die Teams effektiv zusammenarbeiten und ihren Code verwalten können. Azure Test Plans ist eine umfassende Lösung für die Verwaltung, Verfolgung und Planung von Testvorhaben, die sicherstellt, dass qualitativ hochwertige Software bereitgestellt wird.

Azure bietet auch eine Reihe von Erweiterungen und Integrationen für gängige Open-Source-Tools, die seine Funktionen als CI/CD-Plattform ergänzen.

CI/CD in Google Cloud

Google Cloud Platform (GCP) bietet Cloud Build for CI/CD, ein serverloses Produkt, mit dem Entwickler die Build-, Test- und Bereitstellungsphasen in die Cloud verlagern können. In Cloud Build können sie eigene Workflows für die Entwicklung, Prüfung und Bereitstellung über verschiedene Umgebungen hinweg definieren, z. B. VMs, serverlos, Kubernetes oder Firebase.

Google Cloud Source Repositories ist ein zentraler Ort, an dem Teams Code speichern, verwalten und nachverfolgen können, und bietet ein sicheres, skalierbares und hochverfügbares Git-Repository. GCP lässt sich auch mit gängigen Open-Source-Tools wie Git, Jenkins und Spinnaker verknüpfen, für die es eine flexible und umfassende CI/CD-Lösung bereitstellt.

CI/CD in IBM Cloud

IBM Cloud bietet eine umfassende Suite von Tools für die Einrichtung einer CI/CD-Pipeline. Der Service IBM Cloud Continuous Delivery stellt Toolketten bereit, die Integrationen mit Open-Source-Tools und Vorlagen zur Automatisierung der Entwicklung, Bereitstellung und Verwaltung von Anwendungen enthalten.

IBM Cloud Code Engine ist eine vollständig verwaltete serverlose Plattform für die Ausführung containerisierter Workloads, wie Webanwendungen, Microservices, ereignisgesteuerte Funktionen oder Batchaufträge. IBM Cloud lässt sich auch mit gängigen Open-Source-Tools wie Git, Jenkins und Tekton verknüpfen, wodurch es eine vielseitige Option für die CI/CD-Implementierung darstellt.

Best Practices für CI/CD-Pipelines

Zur Verbesserung des DevOps-Workflows und der Softwarebereitstellung empfehlen wir die Beachtung der folgenden Best Practices im Softwareentwicklungszyklus.

Ein einziges Quellcode-Repository

Bei Verwendung eines einzigen Quellcoderepositorys dient dieses zugleich als Quellcode-Management(SCM)-System, in dem alle für die Erstellung von Builds notwendigen Dateien und Skripte zentral gespeichert sind. Das Repository sollte vom Quellcode über die Datenbankstruktur und Bibliotheken bis hin zu Eigenschaftendateien und Versionskontrolle alles enthalten, auch Testskripte und Skripte für die Anwendungsentwicklung.

Ein einziges Quellcoderepository als Ausgangsbasis verbessert die Zusammenarbeit, sorgt für Konsistenz, vereinfacht die Versionskontrolle, verringert das Risiko von Konflikten und erleichtert die Änderungsverfolgung.

Einmalige Builds

Kompilieren Sie den Code und erstellen Sie Build-Artefakte nur einmal und verteilen Sie dann die Artefakte über die Pipeline. Dadurch vermeiden Sie, dass bei Builds in jeder Phase unterschiedliche Artefakte entstehen.

Automatisierung des Build-Vorgangs

Wenn Sie den Build-Prozess (das Konvertieren von Code in ein implementierbares Artefakt) automatisieren, beschleunigen Sie den Entwicklungsprozess und reduzieren das Risiko menschlicher Fehler. Build-Skripte sollten umfassend sein, sodass alles mit nur einem Befehl erstellt werden kann: Webserverdateien, Datenbankskripte, Anwendungssoftware usw. Die CI-Prozesse sollten den Code automatisch kompilieren und zu einer gebrauchsfertigen Anwendung verpacken.

Priorisierung von Automatisierungsvorhaben

Automatisieren Sie so viel wie möglich – von der Code-Integration über die Prüfung und Bereitstellung bis hin zur Einrichtung und Konfiguration der Infrastruktur. Automatisierung steigert die Effizienz und stellt zugleich die Wiederholbarkeit sicher. Sobald Entwickler Code in das gemeinsame Repository laden, löst der CI-Server automatisch einen Build-und-Test-Vorgang aus, bei dem jegliche Probleme sofort angezeigt werden. Diese Vorgehensweise reduziert den Aufwand für die manuelle Integration erheblich, sodass den Entwicklern mehr Zeit für die Weiterentwicklung des Codes bleibt.

Frühes und häufiges Testen

Automatisierte Tests bereits in den frühen Phasen sollten ein fester Bestandteil der Pipeline sein. Führen Sie Komponententests nach der Build-Phase durch, gefolgt von Integrationstests und End-to-End-Tests. Ihre Testskripte sollten einen Build als erfolglos markieren, wenn der Code diese Tests nicht besteht.

Testen in geklonten Umgebungen

Testen Sie neuen Code in einer Kopie der Produktionsumgebung und nicht in der aktiven Produktionsumgebung. Verwenden Sie rigorose Testskripte in dieser geklonten Umgebung, um etwaige Bugs aufzudecken und zu identifizieren, die in den Testläufen vor dem Build nicht aufgefallen sind.

Häufige Bereitstellung

Häufige Bereitstellungen verringern die Batchgröße von Änderungen, wodurch das Aufspüren und Beheben von Problemen erleichtert wird. Außerdem erhalten Entwickler dadurch früher Feedback, Änderungen können (falls nötig) leichter rückgängig gemacht werden und Benutzer erhalten in kürzerer Zeit einen Mehrwert.

CI/CD-Pipeline als einzige Bereitstellungsoption

Verbieten Sie manuelle Bereitstellungen in der Produktion. Alle Änderungen sollten die Pipeline durchlaufen, damit sichergestellt wird, dass jede Änderung getestet wurde, konsistent und rückverfolgbar ist.

Uneingeschränkte Transparenz

Entwicklerteams sollten Zugriff auf die neuesten ausführbaren Dateien sowie einen Überblick über alle Änderungen im Repository haben. Zur Verwaltung der Freigaben sollte die Versionskontrolle verwendet werden, damit die Entwickler jederzeit wissen, welche die aktuelle Version ist.

Optimierung der Feedbackschleife

Richten Sie die Pipeline so ein, dass sie schnell nützliches Feedback gibt. Entwickler sollten umgehend benachrichtigt werden, wenn ihre Änderungen das Fehlschlagen eines Builds oder das Nichtbestehen von Tests zur Folge haben. Schnelles Feedback ermöglicht eine schnelle Fehlerbehebung und sorgt für einen kontinuierlichen Fluss in der Pipeline.

Saubere Umgebungen mit jedem Release

Automatisieren Sie die Säuberung von Test- und Vorbereitungsumgebungen nach jedem Release, um Ressourcen einzusparen und damit jede Bereitstellung in einem sauberen Zustand beginnt.

Leistungskennzahlen für CI/CD-Pipelines

Zyklusdauer oder Zeit bis zur Bereitstellung

Die Zyklusdauer, auch als Zeit bis zur Bereitstellung bekannt, misst die Zeit vom Code-Commit bis zur Bereitstellung. Sie ist einer der wichtigsten Indikatoren für die Effizienz einer CI/CD-Pipeline. Eine kürzere Zyklusdauer ist gleichbedeutend mit einer schnelleren Bereitstellung eines Mehrwerts für die Benutzer und schnellerem Feedback an die Entwickler.

Entwicklungsfrequenz

Die Entwicklungsfrequenz zeigt an, wie oft Codeänderungen an das Versionskontrollsystem geleitet werden. Eine hohe Entwicklungsfrequenz weist auf einen aktiven Entwicklungsprozess mit kleineren, überschaubaren Änderungen hin, die das Fehlerrisiko senken.

Vorlaufzeit für Änderungen

Die Vorlaufzeit für Änderungen misst die Zeitdauer vom Commit einer Änderung bis zu ihrer Bereitstellung als Maß für die Geschwindigkeit der CI/CD-Pipeline. Kürzere Vorlaufzeiten bedeuten, dass früher ein Mehrwert erzielt und Feedbackschleifen schneller durchlaufen werden.

Rate fehlgeschlagener Änderungen

Die Rate fehlgeschlagener Änderungen ist der Prozentsatz der Änderungen, die in der Produktion zu einem Fehler führen. Eine niedrige Rate fehlgeschlagener Änderungen zeigt an, dass der Prozess für die Softwarebereitstellung von hoher Qualität ist. Beeinflusst wird die Rate fehlgeschlagener Änderungen von Faktoren wie der Qualität der Tests sowie den zur Codeüberprüfung und zur Bereitstellung genutzten Praktiken.

MTTR vs. MTTF

Die MTTR (Mean Time to Recovery) und die MTTF (Mean Time to Failure) spiegeln die Zuverlässigkeit der CI/CD-Pipeline wider. Die MTTR ist die durchschnittliche Zeit bis zur Wiederherstellung nach einem Ausfall, während die MTTF die durchschnittliche Zeit zwischen zwei Ausfällen angibt. Eine geringere MTTR und eine höhere MTTF weisen auf eine zuverlässigere Pipeline hin.

CI/CD-Tools

Tools für Continuous Integration

Codefresh

Codefresh, eine für Kubernetes entwickelte CI/CD-Plattform, unterstützt den vollständigen Anwendungsentwicklungszyklus vom Commit bis zur Bereitstellung. Es zeichnet sich durch eine Docker-native Infrastruktur für schnelle und isolierte Builds und eine anpassungsfähige Umgebung für die Entwicklung, Prüfung und Bereitstellung containerisierter Anwendungen aus.

Bitbucket Pipelines

Bitbucket Pipelines ist ein in Bitbucket integrierter CI/CD-Service. Damit können Entwicklungsteams in ihrem Repository eine Konfigurationsdatei für automatisierte Builds, Tests und Bereitstellungen definieren. Seine enge Verknüpfung mit Bitbucket und der Tool-Suite von Atlassian kann die Arbeitsabläufe in Teams, die bereits mit dem Atlassian-Ökosystem arbeiten, erheblich verbessern.

Jenkins

Jenkins ist ein Open-Source-Automatisierungsserver, der zuverlässige Builds, Tests und Bereitstellungen von Software unterstützt. Jenkins bietet umfangreichen Plug-in-Support und verteilte Builds, was es zu einem hochgradig flexiblen Tool für komplexe CI/CD-Pipelines macht.

CircleCI

CircleCI ist eine moderne CI/CD-Plattform, die eine schnelle Entwicklung und Veröffentlichung von Software unterstützt. Der Schwerpunkt liegt auf Einfachheit und Effizienz: Mit intelligentem automatischem Caching, Parallelverarbeitung und Auftragsorchestrierung optimiert CircleCI den Softwarebereitstellungsprozess.

Bamboo

Bamboo, ein weiteres Tool aus der Atlassian-Suite, bietet Funktionen für Continuous Integration und Continuous Delivery mit integrierter Git- und JIRA-Software-Integration. Bamboo ist zwar nicht so erweiterbar wie Jenkins, aber seine vorkonfigurierten Funktionen ermöglichen eine schnellere Einrichtung, was insbesondere für Entwicklungsteams, die eine schnelle und einfache Implementierung brauchen, attraktiv ist.

GitLab CI

GitLab CI ist ein integraler Bestandteil von GitLab und eine robuste Lösung zur Unterstützung des gesamten DevOps-Lebenszyklus. GitLab CI bietet flexible Pipelinekonfigurationen und eine enge Verknüpfung mit der Quellcodekontrolle und Problemverfolgung von GitLab. Damit ist es als Gesamtlösung für die Softwareentwicklung und ‑bereitstellung zu sehen.

Tools für Continuous Delivery and Deployment

Codefresh

Codefresh bietet nicht nur CI-Funktionen, sondern unterstützt auch Continuous Delivery. Durch die Isolierung von Umgebungen und die Unterstützung von Helm-Charts ermöglicht es eine effiziente und zuverlässige Bereitstellung von Kubernetes-Anwendungen.

Argo CD

Argo CD ist ein deklaratives Continuous-Delivery-Tool für Kubernetes in GitOps. Es nutzt Git-Repositorys als Informationsquelle für die Definition von Anwendungen und synchronisiert diese Anwendungen automatisch, wenn im Repository Änderungen festgestellt werden.

GoCD

GoCD ist ein Open-Source-Tool, dessen Schwerpunkt auf der Modellierung und Visualisierung komplexer Arbeitsabläufe für Continuous Delivery liegt. Eine Wertstromkarte bildet den gesamten Weg vom Commit bis zur Bereitstellung ab und unterstützt mit diesem Überblick die bessere Steuerung der Softwarebereitstellungsprozesse.

AWS CodePipeline

AWS CodePipeline ist ein vollständig verwalteter Continuous-Delivery-Service, der Release-Pipelines automatisiert und so Anwendungsupdates beschleunigt und zuverlässiger gestaltet. Als Teil der AWS-Suite lässt sich CodePipeline nahtlos mit anderen AWS-Services verknüpfen. Dies ermöglicht eine effektive Verwaltung und Automatisierung des gesamten Releaseprozesses innerhalb des AWS-Ökosystems.

Azure Pipelines

Azure Pipelines ist ein Teil der Azure DevOps Services von Microsoft. Der Cloud-Service stellt CI/CD-Funktionen für Anwendungen bereit, unabhängig von der Sprache und der Plattform. Es zeichnet sich vor allem durch seine umfassenden Integrationsfähigkeiten (und die resultierende Kompatibilität mit den meisten gängigen Tools und Services in der Entwicklungslandschaft) sowie die unbegrenzten, kostenlosen Build-Minuten für Open-Source-Projekte aus.

Spinnaker

Spinnaker ist eine Multi-Cloud-Plattform für Continuous Delivery, die ursprünglich von Netflix entwickelt wurde. Es bietet hohe Konfigurierbarkeit und leistungsfähige Funktionen für die Bereitstellung mit unterschiedlichen Cloud-Anbietern. Da der Schwerpunkt auf der Bereitstellung liegt, unterstützt Spinnaker eine Reihe von Strategien, darunter Blue/Green-Bereitstellung und Canary-Releases, und ermöglicht so einen hohen Grad der Kontrolle über den Bereitstellungsprozess.

CI/CD-Anwendungen für maschinelles Lernen

MLOps

MLOps ist eine Kombination von maschinellem Lernen (ML) und Betriebsprozessen (Ops) und wurde entwickelt, um den Zyklus der Entwicklung und Bereitstellung von Modellen für maschinelles Lernen zu standardisieren und zu optimieren. Es nutzt CI/CD-Prinzipien für die Automatisierung der Prüfung, Bereitstellung und Überwachung von Modellen für maschinelles Lernen und sorgt so für ihre zuverlässige und konsistente Lieferung.

Techniken für die Erzeugung synthetischer Daten

Bei der Entwicklung von maschinellem Lernen ist die Erzeugung synthetischer Daten ein Verfahren zur Erstellung von Daten, die echte Daten nachahmen. In CI/CD-Pipelines ist dieser Ansatz bei der Prüfung von Modellen für maschinelles Lernen wertvoll, da er ein skalierbares und datenschutzrechtlich unbedenkliches Verfahren zur Evaluierung von Modellen bezüglich der Leistung und der Abdeckung aller zu erwartenden Szenarien bereitstellt.

AIOps-Plattformen

AIOps steht für „Artificial Intelligence for IT Operations” (künstliche Intelligenz für den IT-Betrieb) und integriert KI und maschinelles Lernen in den IT-Betrieb. Im Kontext von CI/CD kann AIOps zahlreiche betriebliche Aufgaben, z. B. Anomalieerkennung, Ereigniskorrelation und Ursachenanalyse, automatisieren und verbessern und so die Effizienz und Effektivität der Softwarebereitstellung steigern.

Sicherheit bei CI/CD

Die Geschwindigkeit und Automatisierung von CI/CD zieht neue Sicherheitsrisiken nach sich, darunter

• Offenlegung oder Verlust sensibler Daten,
• Nutzung nicht sicherer Komponenten von Drittanbietern,
• unbefugter Zugriff, wenn die CI/CD-Tools nicht ordnungsgemäß geschützt sind.

Durch die Priorisierung der CI/CD-Sicherheit mittels DevSecOps (d. h. der Integration von Sicherheitsmaßnahmen und ‑tools entlang der gesamten Pipeline) können Unternehmen dafür sorgen, dass die Software, die sie bereitstellen, die gewünschten Funktionen sicher bereitstellt.

Praktiken der sicheren Codierung

Entwickler müssen die Praktiken der sicheren Codierung befolgen, um zu vermeiden, dass Sicherheitslücken in die Codebasis gelangen. Vorrangige Praktiken sind hierbei die Prüfung von Eingaben, die ordnungsgemäße Reaktion auf Laufzeitfehler und die Einhaltung des Least-Privilege-Prinzips.

Sicherheitstests

Integrieren Sie automatisierte Sicherheitstests in die CI/CD-Pipeline. Tests wie statische Codeanalyse, dynamische Analysen und Penetrationstests können Sicherheitslücken vor der Bereitstellung der Anwendung aufzeigen.

Sicherheit bei der Bereitstellung

Schützen Sie den Bereitstellungsprozess durch die Nutzung sicherer Protokolle für die Datenübertragung sowie die Verwaltung von Zugriffsrechten und Zugangskontrollen während des Bereitstellungsprozesses. Überwachen Sie die Anwendung außerdem in der Produktion, um Sicherheitsvorfälle frühzeitig zu erkennen.

Sichere Architektur der CI/CD-Pipeline

Eine CI/CD-Pipeline mit einer sicheren Architektur ist in jeder Phase mit Sicherheitsmaßnahmen ausgestattet. Nutzen Sie sichere Repositorys für die Quellcodekontrolle, führen Sie Sicherheitsprüfungen während des Build-Prozesses und automatisierte Sicherheitstests durch und sorgen Sie für die Befolgung sicherer Praktiken bei der Bereitstellung.

Sicherheit bei Infrastructure-as-Code

Bei Infrastructure-as-Code (IaC), einer wesentlichen DevOps-Praxis, erfolgt die Verwaltung und Bereitstellung der IT-Infrastruktur über maschinenlesbare Definitionsdateien. Bei der Sicherheit bei IaC geht es um die Verwaltung dieser Definitionsdateien und der mit ihnen erstellten Infrastruktur. Verschlüsseln Sie sensible Daten, beschränken Sie den Zugriff auf die IaC-Dateien und prüfen Sie die Infrastruktur regelmäßig auf die Einhaltung der Sicherheitsrichtlinien.

Sich abzeichnende CI/CD-Trends

Microservices und serverlose Architekturen

Mit der zunehmenden Nutzung von Microservices und serverlosen Architekturen werden CI/CD-Pipelines an komplexere Bereitstellungen angepasst werden müssen. Dies umfasst auch die Bereitstellung und Verwaltung mehrerer untereinander abhängiger Services, von denen jeder potenziell eine andere Technologie und Bereitstellungsplattform nutzt.

Künstliche Intelligenz und maschinelles Lernen

KI und ML finden zunehmend Verwendung zur Optimierung von CI/CD-Pipelines. Die Vorhersage und Vermeidung potenzieller Probleme, Optimierung der Ressourcennutzung und Automatisierung komplexerer Aufgaben sind nur einige denkbare Anwendungsbereiche von KI und ML bei CI/CD.

Infrastructure as Code (IaC)

IaC entwickelt sich zu einer Standardpraxis von DevOps. Je ausgereifter und ausgefeilter IaC-Tools und ‑Praktiken werden, desto größer wird die Rolle sein, die sie in CI/CD-Pipelines spielen.

CI/CD-Pipeline – FAQ