CI/CD ist ein Begriff aus der Softwareentwicklung. Er steht für Continuous Integration (CI – kontinuierliche Integration) und meistens für Continuous Delivery (CD – fortlaufende Auslieferung), seltener für Continuous Deployment (CD – fortlaufende Bereitstellung). CI/CD ein Ansatz, der darauf abzielt, die Codebasis zu automatisieren und die Geschwindigkeit bei der Freigabe von Diensten zu erhöhen.
CI/CD bezeichnet eine Sammlung von Techniken, Tools, Prozessen und Praktiken, die die Entwicklung und Auslieferung von Software verbessert. Entwicklungsteams verwenden dieses Verfahren zur Softwareverteilung mit dem Ziel, Anpassungen des Codes häufiger und zuverlässiger zu implementieren, ohne dabei die Softwarequalität zu beeinträchtigen. CI/CD ist eine Methode der agilen Softwareentwicklung und ein grundlegender Prozess in DevOps-Verfahren. DevOps ist das Bindeglied zwischen Entwicklung und IT-Betrieb. Im Optimalfall ist CI/CD ein Ergebnis der Einführung von DevOps in einer IT-Organisation.
CI/CD bietet einen hohen Automatisierungsgrad bei Test, Implementierung und Ausführung von Codeänderungen und trägt dadurch dazu bei, dass Developer kleine Codeänderungen jederzeit vornehmen können, ohne den Betrieb der Anwendung zu beeinträchtigen. Das CI/CD-Verfahren erkennt Fehler oder Unstimmigkeiten im neuen Code bei automatisierten Tests (Testumgebung) und meldet sie den Entwickler:innen, bevor die Änderungen die Produktiv-Anwendung beeinträchtigen.
Die CI/CD-Pipeline ist der Workflow, der Software von der Entwicklung bis zur Auslieferung begleitet. Das gilt sowohl für die komplette Neuentwicklung einer Anwendung als auch für die Weiterentwicklung. Zur CI/CD-Pipeline gehören drei bis vier Schritte.
Continuous Integration beschreibt das automatisierte Ergänzen eines stabilen Codes durch neuen Code. Das bedeutet, dass neuer Quellcode nicht manuell in den bestehenden Code integriert und der gesamte Code neu implementiert werden muss. Stattdessen werden mithilfe von CI neue Codeteile in Containern bereitgestellt und automatisiert in die bestehende Softwareanwendung eingeführt. Dabei wird der Code und dessen Deployability (Auslieferbarkeit) zuvor getestet, um Probleme erkennen zu können.
Mithilfe von Continuous Delivery wird der Code anschließend mit Tests und Feedback durch CI validiert und automatisch in ein Staging-Repository, also ein zentrales und versioniertes Verzeichnis des Quellcodes, geladen. Dieser Prozess ergibt stabile Änderungen, die lückenlos dokumentiert und nachverfolgt werden können.
Während des gesamten Prozesses wird der neue Quellcode automatisch getestet. Treten Fehler auf, werden die Probleme an die Entwickler:innen weitergeleitet, sodass sie behoben werden können.
Die kontinuierliche Bereitstellung ist der letzte Schritt der Pipeline. Er ist nicht zwingend erforderlich. In dieser Phase wird die neue Softwareversion fortlaufend an die Endbenutzer:innen ausgeliefert. Diese nehmen CD als automatisch bereitgestellte Softwareupdates wahr.
Das CD im Rahmen der Methode ist mehrdeutig. Die Bezeichnung meint sowohl Continuous Delivery als auch Continuous Deployment. Während die fortlaufende Auslieferung zwingend Bestandteil der CI/CD-Pipeline ist, ist die kontinuierliche Bereitstellung ein optionaler Schritt. CI/CD wird inklusive Continuous Deployment verstanden, wenn die Software in der letzten Phase nach einem automatisierten Testing in einem automatisierten Release endet.
Geschieht das nicht, ist mit CD in CI/CD Continuous Delivery gemeint, da der neue Code lediglich in eine isolierte Umgebung integriert wird. Dort können vor dem Release weitere Tests und eine menschliche Qualitätssicherung erfolgen.
Bei vielen Programmen handelt es sich um komplexe Anwendungen, die aus verschiedenen Komponenten bestehen, die wiederum unabhängig voneinander genutzt, entwickelt und verbessert werden. Diese Microservices sind Komponenten oder Features der gleichen Anwendung. Bei umfassenden Anwendungen ist es üblich, täglich Verbesserungen und Weiterentwicklungen in einzelnen Softwarekomponenten vorzunehmen. Die manuelle Durchführung der nötigen Feedback- und Testschleifen würde diese Prozesse deutlich verlangsamen und die Softwarequalität beeinträchtigen.
Durch den Ansatz wird die Codequalität erhöht und Verteilungsprozesse von Software werden einfacher, zuverlässiger sowie vorhersehbarer. Zudem wird die Abstimmung bzw. Zusammenarbeit zwischen (DevOps)-Teams und auch weiteren Abteilungen eines Unternehmens verbessert.
Ein Beispiel aus der Praxis: Klassisch kommt CI/CD aus der Softwareentwicklung, deren Lösungen Stateless sind, also kein persistenter Datenstand vorliegt. Zusätzlich wird von einer Microservice-Architektur ausgegangen. Im (Cloud) Analytics-Bereich liegt das Verständnis für bestehende IT-Systeme allerdings oft monolithisch (alles in einem) und nicht als Microservice vor. Insbesondere im DWH oder im Big Data-Kontext bestehen häufig Stateful-Architekturen. Das bedeutet, dass der Status im System konsistent ist.
Bei jedem Deployment müssen spezielle Schritte beachtet werden, um die technische Infrastruktur konsistent zu halten. Dies wird häufig als Begründung angeführt, dass CI/CD nicht möglich ist. Jedoch können sehr sinnvolle Elemente aus CI/CD eingesetzt werden, die Unternehmen dabei helfen, einen Sprung in der Qualität und Verlässlichkeit ihres Systems zu erlangen.
Sprechen Sie jetzt mit unserem Data & Analytics Experten und wir zeigen Ihnen, wie Sie Ihr Unternehmen auf die nächste Stufe bringen können.
Dürsin Kurt
CEO Cloud Analytics
Zu Wiki Übersicht