Was ist CI/CD?
Isaac Sacolick ist Autor des Amazon-Bestsellers "Diving Digital: The Leader's Guide to Business Transformation thourh Technology". Er schreibt als freier Autor unter anderem für unsere US-Schwesterpublikation CIO.com.
Foto: spainter_vfx - shutterstock.com
Continuous Integration (CI) und Continuous Delivery (CD), auch bekannt als CI/CD, verkörpert eine Kultur, Betriebsprinzipien und eine Reihe von Praktiken, mit denen Entwicklungsteams Änderungen am Code von Anwendungen häufiger und mit höherer Zuverlässigkeit bereitstellen können. CI/CD hat sich sowohl im Umfeld von Devops-Teams als auch in der agilen Methodik bewährt. Durch die Automatisierung von Integration und Bereitstellung ermöglicht CI/CD Softwareentwicklern, sich darauf zu konzentrieren, Geschäftsanforderungen zu erfüllen und parallel qualitativ hochwertigen Code und sichere Software zu gewährleisten.
CI/CD - Definition
Continuous Integration ist eine Coding-Philosophie und ein Set von Praktiken, die Entwicklungsteams dazu befähigen, kleine Änderungen am Code in hoher Frequenz zu implementieren und diese in ein Versionskontroll-Repository einzuchecken. Der Code der meisten modernen Anwendungen wird mit einer Vielzahl von Plattformen und Tools entwickelt. Deshalb benötigen die Entwicklungsteams einen konsistenten Mechanismus, um Änderungen zu integrieren und zu validieren. CI schafft einen automatisierten Weg, um Anwendungen
zu erstellen
zu verpacken und
zu testen.
Ein konsistenter Integrationsprozess ermutigt Entwickler, Codeänderungen häufiger zu übertragen, was zu einer besseren Zusammenarbeit und höherer Codequalität führt.
Continuous Delivery setzt dort an, wo Continuous Integration endet und automatisiert die Bereitstellung von Anwendungen in ausgewählten Produktions-, Entwicklungs- und Testumgebungen. CD schafft einen automatisierten Weg, um Codeänderungen in diese Umgebungen zu übertragen.
CI/CD-Pipeline automatisieren
CI/CD-Tools helfen dabei, die umgebungsspezifischen Parameter zu speichern, die mit jeder Bereitstellung verpackt werden müssen. Die CI/CD-Automatisierung übernimmt anschließend alle erforderlichen Dienstaufrufe an Webserver, Datenbanken und andere Dienste, die neu gestartet werden müssen. Darüber hinaus kann sie auch andere Verfahren nach der Bereitstellung ausführen. Da das Ziel darin besteht, qualitativ hochwertigen Code und Anwendungen bereitzustellen, erfordert CI/CD auch Continuous Testing. Dabei wird unter anderem eine Reihe von automatisierten Regressions- und Leistungstests in der CI/CD-Pipeline ausgeführt.
Ein gutes DevOps-Team mit stabiler CI/CD-Pipeline kann auch Continuous Deployment implementieren. Hierbei durchlaufen Änderungen an der Anwendung die CI/CD-Pipeline, Builds werden direkt in der Produktionsumgebung bereitgestellt. Einige Teams, die das praktizieren, setzen auf tägliche oder sogar stündliche Deployments in die Produktionsumgebung - wobei Continuous Deployment nicht für jede Business-Applikation optimal ist.
Unternehmen, die eine CI/CD-Pipeline implementieren, setzen häufig auf mehrere DevOps-Best-Practices wie:
die Entwicklung von Microservices,
Continuous Testing,
Deployment Container.
Jede dieser Praktiken verbessert die Prozessautomatisierung und macht Cloud-Umgebungen robuster. Zusammen bilden die Best Practices eine solide Grundlage für Continuous Deployment.
Wie Continuous Integration hilft
Continuous Integration ist eine Entwicklungsphilosophie, die von Prozessmechanismen und Automatisierung gestützt wird. Dabei übertragen die Entwickler ihren Code in regelmäßigen Abständen in das Versionskontroll-Repository (in vielen Fällen mindestens einmal täglich). Im Vergleich zu einer umfassenden Änderung, die über einen längeren Zeitraum entwickelt wurde, ist es so einfacher, Fehler und Qualitätsprobleme zu erkennen. Arbeiten Entwickler in kürzeren Commit-Zyklen, sinkt zudem die Wahrscheinlichkeit, dass mehrere Developer dasselbe Stück Code bearbeiten und eine Zusammenführung notwendig wird.
Teams, die CI implementieren, beginnen oft mit der Versionskontrollkonfiguration und den Praxisdefinitionen. Auch wenn häufig Code eingecheckt wird, entwickeln agile Teams Funktionen und Korrekturen in kürzeren und längeren Zeiträumen. Um zu überprüfen, was für die Produktion bereit ist, verwenden Entwicklungsteams, die auf Continuous Integration setzen, verschiedene Techniken.
Dazu gehören etwa Feature Flags, ein Konfigurationsmechanismus, um Code (beziehungsweise Funktionen) zur Laufzeit zu aktivieren oder zu deaktivieren. Features, die noch entwickelt werden, werden mit Feature-Flags "umhüllt", mit dem Main Branch in die Produktion überführt und bleiben deaktiviert, bis sie verwendet werden können. Wie Studienergebnisse zeigen, entwickeln DevOps-Teams, die auf Feature Flags setzen, im Vergleich zu denen die das nicht tun, mit neunfacher Geschwindigkeit. Bekannte Feature-Flagging-Tools sind zum Beispiel:
Diese lassen sich mit CI/CD-Tools integrieren, um Konfigurationen auf Feature-Ebene zu unterstützen.
Automatisierte Builds
Bei einem automatisierten Build-Prozess werden Software, Datenbanken und andere Komponenten in einem Paket zusammengefasst. Entwickeln Sie etwa eine Java-Anwendung, würde Continuous Integration alle statischen Webserver-Dateien wie HTML, CSS und JavaScript zusammen mit der Java-Anwendung und allen Datenbankskripten bündeln. Continuous Integration verpackt jedoch nicht nur alle Software- und Datenbankkomponenten - die Automatisierung sorgt auch für Unit- und andere Tests und gibt den Developern die wichtige Rückmeldung darüber, dass die Änderungen am Code nichts zerstört haben.
Die meisten CI/CD-Tools ermöglichen es Entwicklern, Builds bei Bedarf (ausgelöst durch Code-Commits im Versionskontroll-Repository) oder nach einem festgelegten Zeitplan zu starten. Dafür müssen die Teams den Build-Zeitplan festlegen, der beispielsweise für die Teamgröße und die Anzahl der täglich zu erwartenden Commits am besten geeignet ist. Bewährte Praxis ist es dabei, sicherzustellen, dass Commits und Builds schnell sind - anderenfalls können diese Prozesse die Entwicklungsgeschwindigkeit hemmen.
Continuous Testing und Security Automation
Automatisierte Test-Frameworks helfen QA-Spezialisten dabei, verschiedene Arten von Tests zu definieren, auszuführen und zu automatisieren. Sie sollen ermitteln, ob ein Software-Build tauglich ist oder nicht. Dazu gehören Funktionstests, die am Ende eines jeden Sprints entwickelt und zu einem Regressionstest für die gesamte Anwendung zusammengefasst werden. Dieser gibt Aufschluss darüber, ob eine Codeänderung einen oder mehrere Tests nicht bestanden hat-
Ein bewährtes Verfahren besteht dabei darin, die Entwickler dazu zu verpflichten, alle (oder eine Teilmenge der) Regressionstests in ihrer lokalen Umgebung auszuführen. Das stellt sicher, dass der Code erst dann an die Versionskontrolle übergeben wird, wenn die Änderungen die Regressionstests bestanden haben. Diese sind jedoch nur der Anfang: DevOps-Teams automatisieren auch Testing in den Bereichen
Performance
Browser und
Devices.
Auch statische Codeanalysen und Sicherheitstests lassen sich heute in CI/CD-Pipelines einbetten, um Shift-Left-Testing zu realisieren. Mit Hilfe von Service-Virtualisierung können agile Teams zudem APIs von Drittanbietern, SaaS- und anderen Systemen testen, die außerhalb ihrer Kontrolle liegen. Continuous Testing setzt voraus, dass die CI/CD-Pipeline die Testautomatisierung integriert. Einige Unit- und Funktionstests zeigen Probleme vor oder während des Continuous-Integration-Prozesses an. Tests, die eine vollständige Auslieferungsumgebung erfordern (beispielsweise Leistungs- und Sicherheitstests) werden häufig in die Continuous Delivery integriert und ausgeführt, nachdem ein Build an die Zielumgebungen ausgeliefert wurde.
Die Continuous Delivery Pipeline
Continuous Delivery beschreibt die automatisierte Bereitstellung von Anwendungen in einer oder mehreren Umgebungen. Entwicklungsteams nutzen in der Regel mehrere Umgebungen, um Änderungen für Testing- und Review-Zecke bereitzustellen. Ein DevOps Engineer verwendet dazu CI/CD-Tools. Eine typische Continuous Delivery Pipeline besteht aus Build-, Test- und Deploy-Phasen. Folgende Aktivitäten können in den verschiedenen Phasen enthalten sein:
Code aus der Versionskontrolle ziehen und einen Build erstellen;
Stage Gates für automatisierte Sicherheits-, Qualitäts- und Compliance-Prüfungen aktivieren;
Code in die Zielumgebung verschieben;
Umgebungsvariablen managen und für die Zielumgebung konfigurieren;
Anwendungskomponenten zu den entsprechenden Diensten, wie Webserver, APIs und Datenbankdiensten verschieben;
alle Schritte, die erforderlich sind, um Dienste neu zu starten oder Dienstendpunkte aufzurufen, die für neue Code Pushes benötigt werden.
kontinuierliches Testing und Umgebungen zurücksetzen, wenn Tests fehlschlagen;
Protokolldaten und Warnungen über den Delivery-Status zur Verfügung stellen;
Konfigurationsmanagement-Datenbanken aktualisieren und Meldungen an IT-Service-Management-Workflows senden (bei abgeschlossenen Deployments).
Ausgefeiltere Continuous-Delivery-Pipelines können zusätzliche Schritte wie Datensynchronisierung, die Archivierung von Informationsressourcen oder Patches für Anwendungen und Bibliotheken umfassen. Teams, die Continuous Deployment für die Bereitstellung in der Produktion nutzen, können verschiedene Cutover-Verfahren anwenden, um Ausfallzeiten zu minimieren und Bereitstellungsrisiken zu managen. Eine Option ist die Konfiguration von Canary-Bereitstellungen mit einer orchestrierten Verlagerung des Datenverkehrs von der älteren auf die neuere Softwareversion.
CI/CD-Tools und -Plugins
Zu den gängigen CI/CD-Tools gehören zum Beispiel:
Diese Tools können in der Regel über einen Plugin-Marktplatz erweitert werden. Jenkins listet beispielsweise mehr als 1.800 Plugins auf, unter anderem für die Integration mit Plattformen von Drittanbietern, das User Interface, Administrationsaufgaben, Source-Code- und Build Management. Ist die Tool-Wahl getroffen, müssen Entwicklungsteams sicherstellen, dass alle Umgebungsvariablen außerhalb der Anwendung konfiguriert werden. CI/CD-Tools ermöglichen es, diese Variablen festzulegen, dabei Kennwörter und Kontoschlüssel zu maskieren und sie zum Zeitpunkt des Deployments für die Zielumgebung zu konfigurieren.
Continuous Delivery Tools bieten auch Dashboard- und Reporting-Funktionen, die sich durch die Implementierung von "observable" CI/CD-Pipelines weiter verbessern lassen. Die Dashboard- und Reporting-Funktionen können auch in Versionskontroll- und Agile-Tools integriert werden. Damit sind Entwickler in der Lage festzustellen, welche Codeänderungen und User Stories den Build ausgemacht haben.
Die Auswirkungen der Implementierung von CI/CD-Pipelines können als DevOps KPI gemessen werden. Indikatoren wie die Deployment-Frequenz werden durch eine CI/CD-Implementierung und Continuous Testing häufig optimiert. Continuous Integration und Continuous Delivery ist jedoch nur ein Prozess, der diese Verbesserungen bewirken kann - um die Deployment-Frequenz zu erhöhen, gibt es weitere Voraussetzungen.
CI/CD mit Kubernetes und Serverless
Teams, die CI/CD-Pipelines in Cloud-Umgebungen betreiben, verwenden auch Container wie Docker und Orchestrierungssysteme wie Kubernetes. Mit Containern lassen sich Anwendungen auf standardisierte, portable Weise verpacken und versenden. Container erleichtern es, Umgebungen mit variablen Workloads nach oben oder unten zu skalieren. Um Container, Infrastructure as Code (IaC) und CI/CD-Pipelines zusammenzubringen, gibt es diverse Ansätze. Diese kostenlosen Tutorials unterstützen Sie beim Einstieg:
Serverless-Architekturen zu verwenden, um Anwendungen bereitzustellen und zu skalieren, ist eine weitere Option. In einer Serverless-Umgebung verwaltet ein Cloud-Service-Provider die Infrastruktur, die Anwendung nutzt Ressourcen je nach Bedarf auf der Grundlage ihrer Konfiguration. Bei AWS werden Serverless-Anwendungen beispielsweise als Lambda-Funktionen ausgeführt, Deployments können mit einem Plugin in eine Jenkins CI/CD-Pipeline integriert werden. Ähnliche Dienste stehen mit Azure Serverless und Google Serverless Computing zur Verfügung. (fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.