Continuous Integration (kontinuierliche Integration) und Continuous Delivery (kontinuierliche Auslieferung), in der Kombination als CI/CD, nach der Devops-Methode teils als Pipelining bezeichnet, sind die Sterne am Entwickler-Himmel. Die Konzepte versprechen einen schlanken, effizienten Entwickler-Workflow, der unter Verzicht auf Deadlines und Meilensteine nahezu jederzeit einen aktuellen Projektstand abzubilden in der Lage ist. Das Konzept haben wir in diesem Beitrag näher betrachtet.
Versionsverwaltung ohne CI/CD ist möglich, aber sinnlos
Wenn eine Versionierungssoftware heutzutage ganz vorne mitspielen will, sollte sie sich diesen neuen Ansätzen öffnen und sie bestmöglich unterstützen. Da die kontinuierliche Integration automatisiert in idealer Weise unterstützt werden kann, bietet es sich an, die Methoden in der Versionsverwaltungssoftware weitestgehend abzubilden.
Auf genau diesen Weg hat sich GitHub-Konkurrent GitLab begeben. Schon seit der Version 8 integriert GitLab CI/CD-Methoden. Dabei ist die aktuellste Version 12.7 ein weiterer konsequenter Schritt in Richtung moderner Software-Entwicklung. Deshalb schauen wir genauer hin.
Die Highlights der aktuellen Version der GitLab-Software sind die neuen Parent-Child-Pipelines, das überarbeitete Merge-Request-Management und die Einführung der Pipeline-Resource-Groups.
Parent-Child-Pipelines machen komplexe Prozesse überschaubar
Pipelines sind automatisierte Prozesse, die definierte Aktionen innerhalb der Versionsverwaltungssoftware abarbeiten. Mit steigendem Featureset der hinterliegenden Software können Pipelines ebenfalls immer komplexer werden. Das wirkt sich auf Performance und Admistrierbarkeit aus. GitLab bietet eine Lösung für diese Entwicklung, bevor sie zum Problem wird.
Mit den Parent-Child-Pipelines erlaubt GitLab die Unterteilung komplexer Pipelines in mehrere, potenziell parallel ablaufende. Das soll vor allem eine bessere Visualisierung und damit eine einfachere Verwaltung erlauben. Bei überkomplexen Pipelines können indes auch Performance-Verbesserungen erreicht werden. Definiert werden Parent-Child-Pipelines über eine separate YAML-Datei.
Resource-Groups bringen Pipelines unter Kontrolle
Im gleichen Atemzug ist die Einführung der Resource-Groups zu nennen. Die sollen nämlich dafür sorgen, dass die Parallelisierung der Pipelines kontrollierbar bleibt. Resource-Groups schränken die Verarbeitung verschiedener Pipelines dahingehend ein, dass nur bestimmte Aufgaben aus zuvor angewählten Pipelines gleichzeitig abgearbeitet werden.
Merge-Request-Management steigert den Team-Workflow
In überarbeiteter Form präsentiert sich das Merge-Request-Management. Besonders die Code-Review-Analytics können den Team-Workflow verbessern, weil so schnell zu erkennen ist, welche Merge-Requests noch einer Bearbeitung bedürfen.
Merge Requests im Blick. (Screenshot: GitLab)
Mit dem verbesserten Merge-Request-Widget ist es noch einfacher, zu erkennen, welche Änderungen wann in welcher Umgebung eingeflossen sind.
Mit den Windows-Shared-Runners, die aktuell in einer Beta-Version vorliegen, erweitern die Entwickler die Möglichkeiten, Continuous-Delivery-Prozesse auch unter virtuellen Windows-Maschinen nutzen zu können. Bislang gab es die Shared-Runner nur für Linux.
Die Windows-Shared-Runners kommen als vorkonfigurierte Pakete, die unter anderem das .Net-Framework, die VS-2019-Build-Tools und den Chocolately-Paketmanager enthalten. Preislich will sich GitLab zunächst an den Linux-Shared-Runners orientieren.
Features in allen Versionen enthalten
Die genannten Features sind für alle GitLab-Nutzer ab der Core- respektive Free-Version und damit auch in der gehosteten und selbstgehosteten Variante gleichermaßen verfügbar. Die Windows-Runners waren in der Selfhosting-Version schon zuvor verfügbar.
Mehr Details zum neuen Release, das immerhin 45 neue und verbesserte Funktionen, zwölf Performance-Steigerungen und rund 1.600 Merge-Requests integriert, enthält der Blog-Beitrag des GitLab-Teams.
Wettbewerber GitHub bietet ebenfalls CI/CD
Wettbewerber GitHub unterstützt CI/CD-Methoden über den Marketplace, auf dem Drittanbieter Erweiterungen anbieten können, sowie über Github Actions. GitHub hat sich bei der CI-Integration sehr lange rein auf Drittanbieter verlassen, während GitLab früh erkannt hat, dass diese Methoden in den Produktkern gehören. Von daher hat GitLab einen Vorsprung, gepaart mit einer solideren Integration.
Passend dazu: GitHub vs. GitLab – was lohnt sich wieso?
Seit wann ist Gitlab eine Microsoft Tochter?
Microsoft-Tochter, HÄ???
Seit wann ist GitLab denn eine Microsoft-Tochter? Ich dachte, das wäre Github
Microsoft-Tochter? GitHub?
„Microsoft-Tochter GitLab“ wird im Artikel erwähnt. – Stimmt das oder habe ich was verpasst/falsch verstanden?
Meines Wissens hat Microsoft zwar Git*Hub* gekauft, GitLab aber nicht.
Da habt ihr wohl GitHub mit GitLab verwechselt ;) GitLab gehört der GitLab Inc. und hat nichts mit Microsoft zu tun.
GitLab ist keine Microsoft-Tochter. Das ist GitHub.
GitHUB ist eine Tochter von Microsoft, nicht GitLAB!
„Auf genau diesen Weg hat sich die Microsoft-Tochter GitLab begeben.“
@t3n
Ist GitLab tatsächlich eine Microsoft-Tochter
Wiedermal ein Qualitäts-Artikel von t3n
Vollkommen richtig. Die Windows-Shared-Runners haben mir den Kopf verdreht. GitHub ist natürlich die Microsoft-Tochter und GitLab das eigenständige Unternehmen. Ansonsten ändert es nichts an der Aussage des Artikels. Danke fürs aufmerksame Lesen.