Repetitive und zeitintensive Vorgänge können einiges an Nerven kosten. Mit Hilfe von Automatisierung kannst du verschiedene Prozesse auslagern, um dich zukünftig mit spannenderen Themen zu beschäftigen.
Auch in der Webentwicklung gibt es Arbeitsabläufe, die du automatisieren kannst. Die Integration und das Deployment deines geschriebenen Codes ist einer davon. Die CI/CD Pipeline automatisiert den Prozess von der lokalen Implementierung, über die Testumgebung bis hin zum Produktivsystem. Wie genau das geschieht, schauen wir uns heute einmal an.
Was ist die CI/CD Pipeline?
Die CI/CD Pipeline umfasst die verschiedenen Phasen einer automatisierten Software-Release Pipeline gemäß dem DevOps-Ansatz. Hierbei handelt es sich speziell um Continuous Integration, Continuous Delivery und Continuous Deployment.
Die Phasen der Pipeline werden nacheinander ausgeführt. Dabei kannst du eine CI/CD Pipeline mit oder ohne Continuous Deployment abschließen.
Deshalb kann die Abkürzung CD sowohl für Continuous Delivery wie auch für Continuous Deployment stehen.
Ziel der CI/CD Pipeline ist die Automatisierung von Entwicklungs-, Bereitstellungs- und Testprozessen. Dadurch wird die Entwicklung deiner Idee bis zum Einsatz in der Produktivumgebung beschleunigt, um dort zur Wertschöpfung beizutragen.
Durch Nutzung dieser Pipeline verbesserst du die Qualität und verringerst die Anzahl menschlicher Fehler. Zudem erhöhst du damit die Sicherheit deiner Anwendung.
Continuous Integration
Die Phase von Continuous Integration beinhaltet einen automatisierten Build Prozess. Sobald du deine Codeänderung in die Versionsverwaltung eincheckst, reagiert der Build-Server und stößt einen Build an.
Build
- Als Build wird sowohl der Prozess des Zusammenfügens von Programmteilen als auch die fertige Software-Version bezeichnet.
- Das Erstellen lauffähiger Softwarepakete wird meist durch Build-Tools automatisiert. Diese stellen zugleich die Konsistenz der Rahmenbedingungen zwischen verschiedenen Builds sicher.
Build-Server
- Der Build-Server ist dafür zuständig, die Software zu bauen: sie also zu erstellen und zu kompilieren.
- Du kannst bestimmte Zeitpunkte oder Ereignisse für den Build bestimmen. Hierbei wird der jeweils aktuelle Projektzustand automatisch aus der Versionsverwaltung ausgecheckt, womit der Build durchgeführt wird. Ein Beispiel wäre der Nightly Build.
- Sobald der Build-Server bei jedem Einchecken in die Versionsverwaltung reagiert, wird von Continuous Integration gesprochen.
Continuous Integration kann zudem noch weitere Aufgaben als den reinen Build der Software ausüben. Du kannst etwa Codeanalysen oder automatisierte Tests hinzufügen.
Hier findest du eine Schritt-für-Schritt Anleitung für die Erstellung eines automatisierten Builds mit GitHub Actions.
Continuous Delivery
Wird nach dem Build eine automatische Veröffentlichung der Software in eine nicht-produktive Test- oder Staging-Umgebung angestoßen, sprechen wir von Continuous Delivery. An diesem Punkt kannst du die Software manuell auf die Produktivumgebung veröffentlichen. Zudem kannst du weitere manuelle Gates in die Continuous Delivery Phase integrieren.
Ziel von Continuous Delivery ist es, dass du das zentrale Repository jederzeit in einer Produktivumgebung bereitstellen kannst. Dadurch kannst du mit minimalem Aufwand neuen Code implementieren. Codeänderungen werden nach dem Build automatisch getestet und für eine Produktionsversion vorbereitet.
Dank der Nutzung der Cloud kannst du Testumgebungen einfach und kostengünstig erstellen.
Continuous Deployment
Continuous Deployment ist eine Erweiterung des Continuous Delivery Prozesses. In dieser Phase durchläuft die Software einen automatisierten Testprozess. Dieser endet mit einem automatisierten Release auf die Produktivumgebung.
Die Pipeline läuft also ohne menschlichen Eingriff durch. Deshalb werden hier mehr Disziplin und Genauigkeit gefordert als bei Continuous Delivery.
Ziel der Continuous Deployment Phase ist es den End-User:innen deine Software schneller und kostengünstiger zur Verfügung zu stellen. Das passiert durch das Bereitstellen von kleinen, inkrementellen Softwareänderungen.
Zusammenfassung
Gerade in der Zusammenarbeit mit mehreren Entwickler:innen oder Teams, werden dir die Vorteile einer CI/CD Pipeline schnell auffallen.
Neben der Auslagerung sich wiederholender Aufgaben wird die Code Qualität deutlich gesteigert. Durch das Verwenden automatisierter Tests in den unterschiedlichen Phasen, kannst du negative Auswirkungen der Implementierung schnell erkennen und beheben.
Zudem verhilft dir eine gut konzipierte Pipeline, die Produktivumgebung so aktuell wie möglich zu halten. Big Bang Releases werden von kleinen, kontinuierlichen Releases abgelöst. Somit profitieren deine End-User:innen in kürzeren Zeitabständen von deinen Softwareänderungen.
Quelle Hintergrund des Titelbilds: kostenlose Hintergrundfotos von .pngtree.com
