Was ist Continuous Integration? 

Continuous Integration ist der erste Teil der CI/CD-Pipeline, ein automatisierter DevOps-Workflow, der den Softwarebereitstellungsprozess optimiert. Kontinuierliche Integration ermöglicht es DevOps-Teams, ihre Anwendungen kontinuierlich zu verbessern, konsistentes Feedback zu erhalten, Fehler zu erkennen und zu beheben, bevor sie sich auf die Leistung auswirken, und qualitativ hochwertigere Software zu besser vorhersehbaren Lieferplänen bereitzustellen. 

Wenn ein Entwickler Codeänderungen in einem Haupt- oder gemeinsam genutzten Zweig eines Versionskontrollsystems vornimmt, veranlasst die Aktion ein CI-Tool, einen „Build“ (Erstellungsprozess) der aktualisierten Codebasis durchzuführen. Das CI-System erfasst den neuen Code, kompiliert ihn mit vorhandenem Code und verpackt ihn mit allen Abhängigkeiten, wie Konfigurationsdateien, Bibliotheken oder anderen Ressourcen. Dies ist „der Build“.

Automatisierte Tests werden durchgeführt, um diesen Build zu validieren, bevor ein „Build-Artefakt“ – die resultierende Datei, die zu weiteren Tests oder an eine Produktionsumgebung weitergegeben wird – erstellt wird. Dieser nächste Teil der Pipeline wird als kontinuierliche Bereitstellung bezeichnet.

CI wurde als Lösung für mit der traditionellen Softwareentwicklung verbundene Herausforderungen entwickelt, nämlich deren Integrations- und Bereitstellungsprozesse. In traditionellen Entwicklungsparadigmen ist jeder Entwickler für die manuelle Integration von neuem Code in neue Iterationen einer App oder eines Dienstes verantwortlich, was die Integration zu einem zeitaufwändigen und fehleranfälligen Prozess macht, insbesondere für große Entwicklungsteams.

Verschiedene Codeteile funktionierten nicht immer gut zusammen, und die Entwickler integrierten ihre Änderungen zu unterschiedlichen Zeitplänen (manchmal in letzter Minute), sodass sich das Feedback zu Integrationsproblemen oft verzögerte. Wenn Probleme auftraten, machten es die Verzögerungen beim Feedback für die Teams schwieriger, herauszufinden, welche Änderung das Problem verursachte, und machten die Fehlersuche zu einem mühsamen Prozess.

Darüber hinaus wurden Softwaretests nur selten durchgeführt. Teams implementierten in der Regel große Batch-Updates auf einmal, wodurch Fehler durch die Maschen schlüpfen und sich in der Codebasis ansammeln konnten. Infolgedessen sahen sich die Entwicklungsteams mit anspruchsvolleren Fehlerbehebungsaufgaben, höheren Fehlerraten und langsameren Codefreigaben konfrontiert; Unternehmen verloren Umsatz, weil sie ineffiziente Prozesse verarbeiteten; und die Benutzer sahen mehr Softwarefehler und Störungen.

Kontinuierliche Integration – eine grundlegende Komponente moderner DevOps-Praktiken, kontinuierliche Integration/kontinuierliche Bereitstellung (CI/CD)-Pipelines und Microservices-Architekturen – hilft bei der Rationalisierung des Build-Prozesses, indem sie schnelles Feedback zur Integrationsleistung liefert.

Bei einem CI-System wird neuer Code zu einem zentralen Repository hinzugefügt (in der Regel mehrmals am Tag), wo er zum Erstellen und Testen verbleibt. Wenn das System einen Fehler entdeckt, versendet es Benachrichtigungen, korrigiert den Code und bestätigt, dass der aktualisierte Code korrekt ist, bevor es ihn vollständig mit der Codebasis der Software zusammenführt.

Während die genaue Konfiguration eines Continuous-Integration-Systems von Team zu Team und von Unternehmen zu Unternehmen variiert, verwendet jedes CI-System bestimmte Komponenten und Prozesse, um Codeintegrationsaufgaben zu optimieren.

CI beginnt mit einem zentralen, gemeinsam genutzten Repository, in dem alle Entwickler ihren Code festschreiben. Zentrale Repositories dienen als Eckpfeiler der CI-Praktiken. Diese Repositories werden häufig von Versionskontrollsystemen (VCS) wie Git und Bitbucket verwaltet. Wenn Entwickler Änderungen einreichen, werden sie im zentralen Repository nachverfolgt und es wird eine vollständige Historie der Codeänderungen erstellt, die die Entwicklungsteams zur effizienteren Zusammenarbeit nutzen können.

Repositories verwenden außerdem Branching-Techniken, die separate Entwicklungslinien erstellen, um laufende Codeänderungen von der Hauptcodebasis (dem Haupt-Branch) zu isolieren und eine parallele Entwicklung zu ermöglichen. Durch Branching können Entwickler Feature-Branches (zum Isolieren bestimmter App-Funktionen) und kurzlebige Branches erstellen, um ihre Arbeit zu trennen, bevor sie sie wieder in den Hauptcode-Branch einfügen.

Gitflow ist beispielsweise ein Git-basiertes Verzweigungsmodell, das verschiedenen Branches Rollen (wie „main“, „Funktion“, „develop“ und „release“) zuweist, um zu steuern, wie sie miteinander interagieren. Gitflow-Branches erfordern, dass Entwickler Funktions-Branches erstellen und warten, bis die Funktion abgeschlossen ist, um Codeänderungen in den Haupt-Branch zu integrieren.

CI-Server sind Tools, die alle CI-Vorgänge zentralisieren und verwalten. Sie dienen als Automatisierungszentrum für den CI-Prozess. CI-Server überwachen Repositorys auf Codeänderungen und initiieren und betreiben vordefinierte CI-Pipelines, wenn Änderungen erkannt werden. CI-Server führen automatisierte Builds, Tests und Software-Releases aus; orchestrieren Versionskontrollprotokolle; bearbeiten Statusberichte; und unterstützen Plug-Ins, die die Systemfunktionalität verbessern können.

Viele CI-Server verfügen über Benutzeroberflächen, die Teams dabei helfen, Arbeitsabläufe zu modellieren und zu visualisieren und ihre Continuous-Delivery-(CD-)Pipelines zu erstellen.

CI-Systeme ermutigen Entwickler, mehrmals täglich Codeänderungen weiterzugeben und dabei kleine, gezielte Änderungen an bestimmten Aufgaben oder Funktionen zu priorisieren. CI-Tools ermöglichen es Teams, Reviews einzuleiten und Probleme zu besprechen, bevor sie neuen Code zusammenführen, sodass Fehler früher im Entwicklungsprozess erkannt werden.

Ein Git-basiertes CI-System kann beispielsweise Pull Requests initiieren, um Codeänderungen aus einem lokalen Zweig (lokal auf dem Computer eines einzelnen Entwicklers gespeichert) abzurufen und sie in den aktuellen Remote-Zweig zu integrieren (entfernt gespeichert und vom gesamten Entwicklungsteam gemeinsam genutzt). Anforderungen an die Zusammenführung ermöglichen es Entwicklern, Änderungsvorschläge von einer lokalen Niederlassung in eine andere lokale Niederlassung zu integrieren, um sie im Team zu prüfen, zu diskutieren und zu genehmigen, bevor sie mit der entfernten Niederlassung zusammengeführt werden.

Server und Tools für kontinuierliche Integration (einschließlich beliebter Open-Source-Tools wie Jenkins, CircleCI, GitHub, AWS CodePipeline und GitLab CI) überwachen das zentrale Repository auf Codeänderungen. Wenn sie eine neue Änderung erkennen, lösen CI-Server den Build-Prozess aus und führen vordefinierte Workflows und Build-Skripte aus. Sie kompilieren und verpacken den Code, um ihn auf das Testen und schließlich auf die Bereitstellung vorzubereiten.

CI-Tools führen eine Reihe von Tests durch, um den Code zu validieren, bevor er mit der Codebasis zusammengeführt wird. Unit-Tests validieren einzelne Komponenten oder Funktionen und liefern sofortiges Feedback zum Codeverhalten. Integrationstests bewerten die Interaktionen zwischen Softwarekomponenten und -modulen, um sicherzustellen, dass sie korrekt zusammenarbeiten, und um Fehler aufzudecken, die in Unit-Tests möglicherweise übersehen wurden.

In einigen CI-Workflows wird die Software durch End-to-End-Tests validiert, indem Anwenderinteraktionen simuliert werden, um zu überprüfen, ob sich die Software aus der Sicht eines Anwenders korrekt verhält. Teams können auch Codequalitätstests und statische Analysen durchführen, um die Reaktionsfähigkeit und Stabilität der Anwendung unter Last zu überprüfen und Verstöße gegen Codierungsstandards und Sicherheitslücken zu identifizieren.

CI-Server benachrichtigen Entwickler sofort, wenn ein Build oder Test fehlschlägt. Wenn ein Fehler auftritt, können Entwickler die Reparatur des Codes priorisieren, um sicherzustellen, dass der Haupt-Branch bereitstellbar bleibt.

Wenn ein Software-Build erfolgreich ist, erzeugen die Server Artefakte – Dateien wie kompilierter Code, Docker-Images und Bibliotheken, die während des Build-Prozesses erstellt werden –, die versioniert und in Repositorys für zukünftige Tests und Bereitstellungen gespeichert werden. Unabhängig vom Ergebnis protokollieren führende CI-Systeme Integrationsversuche, Erfolgsraten und andere Metriken, um sicherzustellen, dass Teammitglieder jederzeit auf eine umfassende Versionsdokumentation zugreifen können.

Tests sind ein wichtiger Bestandteil kontinuierlicher Integrationsprozesse. Tests machen mindestens ein Drittel der CI-Aktivitäten aus, aber das gilt nur, wenn Teams eine einzige Testphase durchführen. Oft machen Testaktivitäten den größten Teil der Workload für CI-Tools aus. 

Kontinuierliches Testen in einer CI-Umgebung beginnt, wenn ein Entwickler neuen Code in eine Codebasis überträgt. Diese Aktion löst einen Build- und einen automatisierten Testprozess aus. In vielen Fällen werden zusätzliche Tests durchgeführt, sobald ein Build-Artefakt erstellt wurde (bevor der Code in die Produktion geht). Es ist auch wichtig, dass Entwickler Tests – und Teile von Tests – in ihrer lokalen Umgebung ausführen, um sicherzustellen, dass sie den Quellcode erst dann der Versionskontrolle übergeben, wenn die Tests der neuen Codeänderungen erfolgreich waren.

Dieses vielschichtige Testen verschiedener Funktionen, Anwendungsfälle und Integrationen wird zusammenfassend als Test-Suite bezeichnet. Dieser Ansatz maximiert die Testabdeckung, verhindert eine Code-Regression und legt den Grundstein für eine erfolgreiche kontinuierliche Bereitstellung.

Testgetriebene Entwicklung (TDD) ist ein weiterer Ansatz zur Softwareentwicklung. TDD ist ein Ansatz, bei dem Entwickler „rückwärts arbeiten“ und einen Test schreiben, bevor sie Code schreiben. Bei diesem Ansatz schreiben die Entwickler einen Unit-Level-Testfall, der fehlschlägt, bevor sie das Minimum an Code schreiben, um ihn erfolgreich zu machen. Sobald dies erledigt ist, können sowohl der Test- als auch der Produktionscode überarbeitet und verbessert werden.

Dieser Ansatz hilft Entwicklern, sich auf klar definierte Anforderungen zu konzentrieren und überflüssigen Code zu vermeiden. Es legt außerdem Wert auf kontinuierliches Feedback und kann eine erfolgreiche Technik zur Beschleunigung von Entwicklungszyklen sein.

DevOps-Pipelines beschleunigen die Bereitstellung hochwertiger Software, indem sie die Bemühungen von Entwicklungs- und IT-Betriebsteams, die früher nur in ihrer eigenen Welt lebten, automatisieren und kombinieren.

Erfolgreiche DevOps-Prozesse und -Kulturen gehen über die Entwicklung und den Betrieb hinaus und umfassen Plattform- und Infrastrukturtechnik, Sicherheit, Compliance, Governance, Risikomanagement, Geschäftsbereiche, Endnutzer und Kunden. Das bedeutet, dass gute DevOps die Beiträge aller Anwendungsstakeholder in den Softwareentwicklungslebenszyklus einbeziehen sollte.

Im DevOps-Framework steht die kontinuierliche Integration am Anfang des Softwareentwicklungsprozesses und der CI/CD-Pipeline. CI ermöglicht es Entwicklern, ihren Code häufig zu überprüfen, um zu verhindern, dass sich lokale Kopien zu weit vom Hauptzweig des Code-Builds entfernen. Dieser Ansatz hilft Teams, Merge-Konflikte zu vermeiden, die den Build in der Delivery- und Bereitstellungsphase „unterbrechen“ könnten.

CI ermöglicht es den Entwicklern auch, kleine, häufige Updates abzusenden, die schnelle, konsistente Feedbackschleifen und kontinuierliche Verbesserungen auf der Grundlage der Priorisierung von Kundenbedürfnissen fördern – wichtige Grundsätze der DevOps.

Die kontinuierliche Integration ist die erste Station in der CI/CD-Pipeline, gefolgt von Continuous Delivery- und Continuous Deployment-Prozessen (kontinuierliche Bereitstellung). Kontinuierliche Integration bezieht sich auf häufige Codezusammenführungen und die darauf folgenden Build- und Komponententests.

Continuous Delivery (CD) setzt dort an, wo Continuous Integration aufhört, und automatisiert die Bereitstellung validierter Codebasisänderungen (einschließlich Updates, Fixes und sogar neuer Funktionen) in ausgewählte Umgebungen oder Code-Repositorys. DevOps-Teams erhalten Benachrichtigungen über den neuesten Build und können die Updates manuell in eine Live-Produktionsumgebung verschieben. 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, bevor der Code live geht.

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.¹

Agile Entwicklung ist ein iterativer Ansatz für die Softwareentwicklung, bei dem Flexibilität, Zusammenarbeit, kontinuierliche Verbesserung und schnelle Anpassung an Veränderungen im Vordergrund stehen. Es handelt sich dabei um eine Praxis, die Entwicklung in kleinere Arbeitsgruppen – oder „Sprints“ – organisiert, um die Zusammenarbeit zwischen Entwicklern und Stakeholdern zu optimieren und die Softwarebereitstellung zu beschleunigen.

Ebenso erfordert CI häufige, inkrementelle Code-Updates und eine kontinuierliche Code-Validierung. Es handelt sich um einen iterativen Entwicklungsansatz, der es Entwicklern ermöglicht, Softwarelösungen im Laufe der Zeit schnell zu aktualisieren und zu skalieren und den Benutzern schneller hochwertige Produkte zu liefern. Kontinuierliche Integration ist daher eine von Natur aus flexible Praxis. 

Kontinuierliche Integration hilft Entwicklungsteams, schneller zu iterieren und den Benutzern bessere Software zur Verfügung zu stellen, aber es gibt noch weitere Schritte, die ein Unternehmen zur Optimierung des Prozesses unternehmen kann. Zu den häufig implementierten CI-Verfahren gehören:

Mit kontinuierlichen Integrationsverfahren – und DevOps-Frameworks im weiteren Sinne – können Unternehmen die Zusammenarbeit und Code-Integration optimieren und Continuous Delivery-Pipelines pflegen. Solche Praktiken verbessern die Softwarequalität und beschleunigen die Software-Release-Prozesse. Moderne CI-Tools umfassen eine Reihe neuer Technologien, die diese Praktiken stärken und ihren Wert steigern.

So wird beispielsweise der Einsatz von künstlicher Intelligenz (KI) und maschinellem Lernen (ML) in kontinuierlichen Integrationsprozessen zur Standardpraxis in der Entwicklung. Mit KI-fähigen Tools erstellen Entwickler Systeme mit automatischer Fehlerbehebung, die problematischen Code automatisch und autonom identifizieren und korrigieren, bevor er sich auf den Hauptentwicklungsstrom auswirkt. ML-gesteuerte CI-Systeme generieren auch automatisch maßgeschneiderte Testfälle auf der Grundlage von Codeeinreichungen und -änderungen, sodass Entwickler weniger Zeit mit der manuellen Erstellung von Codetests verbringen.

Angesichts der immer ausgefeilteren Cyberbedrohungen² integrieren Entwickler zunehmend Sicherheitspraktiken direkt in den Softwareentwicklungsprozess. Diese „Shift-Left“-Sicherheitsstrategien führen Sicherheitsprüfungen in den frühesten Phasen der Entwicklung – einschließlich CI-Prozessen – ein, um sicherzustellen, dass Schwachstellen bereits während der Codierung und nicht erst nach der Bereitstellung erkannt werden.

Heute bilden Kubernetes und das erweiterte Ökosystem von Container-Technologien die Bausteine moderner IT-Umgebungen. DevSecOps integriert Sicherheit in jede Phase von DevOps, um die Sicherheitsherausforderungen zu begegnen, die mit solchen dynamischen Ökosystemen einhergehen.

Container sind ausführbare Softwareeinheiten, die Anwendungscode zusammen mit seinen Bibliotheken und Abhängigkeiten verpacken, sodass der Code in jeder Computerumgebung ausgeführt werden kann. Und Kubernetes – auch bekannt als k8s oder kube – ist eine Open-Source-Containerorchestrierungsplattform für die Planung und Automatisierung der Bereitstellung, Verwaltung und Skalierung von containerisierten Anwendungen.

Traditionell verließen sich DevOps-Teams bei der Identifizierung von Schwachstellen auf ein separates Sicherheitsteam und nutzten das Feedback dann, um Codeänderungen in der nächsten Runde der App-Updates zu implementieren. Jetzt wird von den Entwicklern erwartet, dass sie Container und Cluster sichern und Zero-Trust-Prinzipien in ihren Anwendungen und im Entwicklungsprozess anwenden, was ein neues operatives Paradigma widerspiegelt^.3 Die Einführung von DevSecOps-Praktiken bedeutet, dass es bei der Programmierung und Softwareentwicklung nicht mehr nur darum geht, Funktionen zu entwickeln, sondern auch darum, Risiken zu antizipieren.

Serverloses Computing und cloudnative Architekturen haben für die heutigen DevOps-Teams ebenfalls Priorität.

Serverless Computing ist ein Modell für die App-Entwicklung und -Ausführung, mit dem Entwickler Anwendungscode erstellen und ausführen können, ohne Server oder Backend-Infrastrukturen bereitzustellen oder zu verwalten. Die Server in einer serverlosen Konfiguration sind zwar vorhanden, aber sie werden vollständig von einem Cloud-Service verwaltet. In CI-Pipelines befreien Serverless-Plattformen die Entwickler von den Problemen der Backend-Infrastruktur, sodass sie sich auf die Front-End-Codierung und die Geschäftslogik konzentrieren können.

Angesichts der zunehmenden Verbreitung von serverlosem Computing und KI-Anwendungen spielen ereignisgesteuerte Architekturen (EDAs) eine bei der Bewältigung der zunehmenden Komplexität des Cloud Computings. EDAs unterstützen die Echtzeitkommunikation zwischen lose gekoppelten Frontend- und Backend-Systemen und ermöglichen es den Systemen, unabhängig zu arbeiten und Ereignisse (jede Änderung oder Aktion, die innerhalb eines Systems stattfindet) asynchron zu verarbeiten.

In CI-Pipelines bedeutet dies, dass Entwickler einzelne App-Komponenten skalieren können, ohne dass sich dies auf die gesamte Anwendung auswirkt, was die Erstellung flexiblerer, reaktionsschnellerer und skalierbarer Codebases und Integrationsprozesse ermöglicht.

Das Einrichten einer robusten CI-Pipeline erfordert eine sorgfältige Planung und Konfiguration, einschließlich der Auswahl der richtigen Tools, der Definition von Build- und Test-Workflows und der Konfiguration der Infrastruktur. CI-Pipelines müssen auch regelmäßig gewartet werden, um Änderungen an der Codebasis, Abhängigkeiten (wie APIs) und der Infrastruktur zu berücksichtigen.

Die Implementierung von CI kann Softwareentwicklungsteams jedoch eine Reihe von Vorteilen bieten, darunter:

Mithilfe von CI-Prozessen lassen sich Fehler frühzeitig beheben – manchmal innerhalb von Minuten nach dem Senden von Code.

Jeder im Team kann Code ändern, Codeänderungen zusammenführen und Codeinkompatibilitäten und Integrationsfehler identifizieren. Dies vereinfacht den Wissensaustausch und verbessert die Code- und Softwarequalität durch Peer-Feedback.

Da laufend neuer Code integriert wird, verbringen die Teams weniger Zeit mit der Integration und dem Testen großer Code-Batches. Und dank der beschleunigten Feedbackschleife, die CI-Tools bieten, können Entwickler Software-Updates und neue Produkte schneller iterieren und für Endbenutzer bereitstellen.

Häufige Übertragungen von Codes führen zu kleineren und inkrementelleren Änderungen, die leichter zu verstehen, zu überprüfen und zu testen sind. Dies verringert das Risiko, dass während der Entwicklung erhebliche Fehler in die Codebasis eingeschleust werden.