GitLab CI/CD
GitLab CI/CD
Continuous Integration (CI)
Die Praktik der Continuous Integration ist ein Bestandteil der agilen Softwareentwicklung: Möchte ein Entwickler ein Feature implementieren, so erstellt dieser sich, kontrolliert von einem Versionsverwaltungssystem, einen separaten Feature-Zweig, in welchem die Änderungen vorgenommen werden. Features werden so kleinteilig wie möglich implementiert und ebenso so schnell wie möglich wieder mit dem Hauptzweig des Projekts vereint. Beim Vereinen (mergen) von Branches werden die Änderungen automatisiert getestet und die Software gebaut, um im Entwicklungsprozess sicherzustellen, dass die Integration des neuen Features problemlos möglich ist. Diese Vorgehensweise ermöglicht das parallele Arbeiten an einem Projekt mit geringem Risiko und in kurzer Zeit, jeder Entwickler ist nahezu zu jeder Zeit auf dem neuesten Entwicklungsstand, sodass es keine komplizierten Merges bzw. Integrationen des Features in den Hauptzweig geben sollte, durch Tests beim Integrieren sinken die Chancen auf Bugs.
Continuous Delivery und Deployment (CD)
Zwei Aspekte der Continuous Integration sind Continuous Delivery und Continuous Deployment.
Ersterer beschreibt, dass zu jedem Zeitpunkt in der Entwicklung die Software korrekt kompiliert bzw. “baubar” ist. Dies wird erreicht, indem neue Features umgehend integriert werden sowie die Software automatisch getestet, kompiliert und in die Produktiv-/ Testumgebung eingebunden wird. Dies geschieht über eine Pipeline. Dem Auftraggeber der Software kann also jederzeit eine funktionsfähige Software im aktuellen Stand vorgezeigt werden.
Continuous Deployment führt Delivery noch einen Schritt weiter: die automatisch deployte Software wird automatisch in die Produktivumgebung eingebunden und veröffentlicht. Unternehmen bevorzugen normalerweise aber gestaffelte Deployments, sodass nicht jedes Feature sofort veröffentlicht wird.
Git und GitLab
GitLab ist eine Versionsverwaltungssoftware (VCS) zum hosten auf einem eigenen Server, die auf der Open-Source Software Git basiert und 2011 von den Ukrainern Dmitri Saparoschez und Valery Sizov entwickelt wurde. Privat ist GitLab in der Community Edition kostenlos, die Enterprise Edition für Unternehmen ist kostenpflichtig, nach dem Kauf der Konkurrenz-Plattform GitHub durch Microsoft im Jahr 2018, erlebte GitLab einen deutlichen Zuwachs an Nutzerzahlen.
Die Hauptaufgabe eines VCS ist es, Änderungen an Quellcode bzw. Dateien zu verfolgen und zu speichern, sodass diese Änderungen nachvollzogen und im schlechtesten Fall auch rückgängig gemacht werden können. Die Projekte werden als Archive (Repositories) organisiert, welche Ordnerstruktur und Dateien beinhalten. Wie bereits weiter oben angerissen, ist das Verzweigen von Entwicklungsständen (Branches) ein zentraler Bestandteil von Git, sodass unabhängig vom Hauptzweig entwickelt und danach wieder miteinander vereinigt werden kann. Zusätzlich zu den Git Funktionen bietet GitLab Tools fürs Projektmanagement wie z.B. Issue Tracking und Kanban-Board zum Zuteilen und Verfolgen der Aufgaben im Team. Mit Pipelines ist es möglich, mit dem Prinzip von CI/CD agil zu entwickeln.
Pipelines
Die CI/CD Pipelines sind eine Kernkomponente von GitLab. Diese werden über eine .gitlab-ci.yml Datei konfiguriert und werden durch bestimmte Trigger ausgelöst, z.B. beim Erstellen eines Branches oder beim Erstellen einer Merge Request. Dann werden nacheinander Stages bzw. Jobs auf einem Runner, einer Art virtuellen Maschine, ausgeführt, die Code z. B. kompiliert, testet und deployt.
Über das GitLab Pages Feature können direkt über die Pipeline statische Webseiten erzeugt und selbst oder über die GitLab Domäne gitlab.io veröffentlicht werden.
Stages und Jobs
Jobs werden auf einem Runner ausgeführt und stellen die einzelnen Bausteine einer Pipeline dar. Jeder Job hat einen Namen und wird in der Konfigurationsdatei der Pipeline wie in folgendem, simplen Beispiel definiert:
Einzelne Anweisungen stellen Befehle in der Kommandozeile dar. Jobs müssen aber nicht ausschließlich durch Pipelines ausgeführt werden, sondern z. B. auch durch einen REST-API-Call oder manuell über das Web-Interface. Auch Abhängigkeiten können über das Schlüsselwort “needs:” dargestellt werden, sodass die Reihenfolge der Ausführung festgelegt werden kann. Standardmäßig werden alle Jobs parallel ausgeführt, sofern genug Runner vorhanden sind.
Jobs sind über Stages gruppierbar. Der Unterschied zu losen Jobs liegt darin, dass Stages nacheinander ausgeführt werden, sodass nur die Jobs innerhalb einer Stage gleichzeitig ausgeführt werden und nicht alle gleichzeitig. Das ist nützlich, wenn z. B. Quellcode erst über Jobs kompiliert und danach getestet und veröffentlicht werden soll. Im obigen Bild sind die Stages build, test und deploy definiert. Es kann erst getestet werden, wenn die Software erfolgreich kompiliert wurde. Die Konfiguration erfolgt über das Schlüsselwort „stage:“.
Ein BPMN-Diagramm verdeutlicht den Ablauf:
Variablen
CI/CD Variablen sind Umgebungsvariablen, die das Verhalten von Jobs und Pipelines beeinflussen sowie Werte in Job-Skripts setzen können, z. B. zum Speichern von Ordnerpfaden und Secrets/ Passwörtern. Es gibt neben selbst definierten- auch vordefinierte Variablen wie z. B. $CI_JOB_STAGE, welche die Bezeichnung der aktuellen Stage zurückliefert. Variablen können entweder in der Pipeline-Konfigurationsdatei oder über die GitLab-Weboberfläche definiert werden, letztere Möglichkeit sollte für Tokens oder Passwörter verwendet werden, um diese nicht zu veröffentlichen.
Git Hooks
Hooks sind ein grundlegender Bestandteil des Git Ökosystem und können in “.git/hooks” als automatische Abläufe definiert werden. Diese werden entweder auf dem Server oder auf dem Client ausgeführt. Serverseitige Hooks sind zum größten Teil durch Pipelines abgelöst. Clientseitige Hooks können durch die Flag “–no-verify” übergangen werden. Serverseitige Hooks werden nicht übersprungen. Die Dateien beinhalten Bash-Scripts, welche an der entsprechenden Stelle innerhalb des Commit- und Merge-Prozesses an entsprechender Stelle ausgeführt werden.
Pre Commit
Diese Hook wird noch vor dem Commiten von dem Client ausgeführt. Somit bietet diese die möglichkeit den Codestyle zu überprüfen und zu modifizieren, bevor diese commitet wird.
An dieser Stelle werden Linter genutzt um einen einheitlichen codestil zu gewährleisten.
Alternativen
GitHub
Ähnlich wie das Vorgehen von GitLab ist es unter Microsofts GitHub auch möglich, Praktiken von Continuous Integration und Continuous Deployment zu implementieren. Hierbei gibt es die GitHub Actions, diese können kostenlos bei öffentlichen Repositories und über selbst gehostete Runner bei privaten Repositories die Pipeline (unter Github Workflow) ausführen. Hierbei werden die verschiedenen Stages (unter Github Actions) über den Runner ausgeführt. Das Nutzen eines von GitHub gehosteten Runner bietet die Möglichkeit, beispielsweise Integrationstests auf Linux, Microsoft und Mac Betriebssystemen durchgeführt werden.
Azure
Ebenso von Microsoft verfügt Azure über die Möglichkeit, eine Pipeline zu konfigurieren, mit der es möglich ist, die CI/CD-Anweisungen auszuführen. Diese funktioniert wie GitHub Workflow und orientiert sich syntaktisch stark daran.