GitLab Downstream-Pipelines

GitLab Downstream-Pipelines ermöglichen eine effektive Strukturierung von CI/CD-Prozessen, indem sie Aufgaben trennen und die Wartbarkeit sowie Effizienz verbessern. In diesem Blogartikel beschreiben wir, was Downstream-Pipelines sind, welche Arten es gibt und wie sie verwendet werden. 

Wozu Downstream Pipelines verwenden?

In größeren Projekten können CI/CD-Pipelines oft groß und unübersichtlich werden, was ihre Wartung erschwert und Fehler begünstigt. Um übergroße Pipelines zu vermeiden, können sogenannte Downstream-Pipelines eingesetzt werden, die es ermöglichen, von einer Pipeline aus, andere Pipelines zu triggern.

Diese Strukturierung fördert nicht nur eine klarere Trennung der Aufgaben, sondern ermöglicht auch eine bessere Visualisierung der Abläufe in GitLab, besonders bei mehrstufigen Deployment-Prozessen. Das Verwenden dieser Art von Pipelines bringt verschiedene Vorteile mit sich, wie beispielsweise eine erhöhte Wartbarkeit, da jede Pipeline unabhängig optimiert bzw. angepasst werden kann. Mehrere Downstream-Pipelines können parallel ausgeführt werden, wodurch die Gesamtlaufzeit der CI/CD-Pipeline deutlich verkürzt werden kann. 

Anwendungsbeispiel

Nehmen wir an, wir entwickeln eine Webanwendung und setzen verschiedene Umgebungen wie Entwicklung, Staging und Produktion ein. Wir möchten sicherstellen, dass neue Features getestet werden, bevor es in die Staging- und schließlich in die Produktionsumgebung übergeht. Wenn ein:e Entwickler:in ein neues Feature entwickelt, wird dieses mithilfe von automatisierten Tests gründlich getestet. Dafür können Downstream-Pipelines sinnvoll verwendet werden. Die Hauptpipeline wird aktiviert und führt Jobs aus, welche Tests in der Entwicklungsumgebung durchführen. Sobald diese Tests erfolgreich sind, wird ein Trigger-Job gestartet, der die Pipeline in der Staging-Umgebung aufruft. Auch dort werden wieder Tests ausgeführt, bevor das Feature schließlich in die Produktionsumgebung überführt wird. Dieser strukturierte Prozess gewährleistet, dass neue Funktionen umfassend geprüft werden, bevor sie live geschaltet werden, was die Stabilität und Zuverlässigkeit der Anwendung erheblich erhöht. 

Welche Arten von Downstream-Pipelines gibt es?

Unterschieden wird zwischen zwei Arten von Downstream-Pipelines, nämlich Parent-Child-Pipelines und Multi-Project-Pipelines. Beide werden oftmals für denselben Zweck verwendet, es gibt jedoch ein paar wichtige Unterschiede.

Eine Parent-Pipeline triggert eine Downstream-Pipeline innerhalb desselben Projekts. Diese ausgelöste Pipeline wird als Child-Pipeline bezeichnet. Sie läuft im gleichen Projekt, mit dem gleichen Commit-Hash und im selben Branch wie die Parent-Pipeline. Diese Struktur ermöglicht es, komplexe Workflows durch eine strukturierte Abfolge von Pipelines abzubilden. Ein Vorteil von Parent-Child-Pipelines ist, dass sie unabhängig voneinander ausgeführt und überwacht werden können, was die Fehlerbehebung erleichtert und die Wartbarkeit erhöht.

In einer Multi-Project-Pipeline ist die übergeordnete Pipeline in der Lage, eine nachgelagerte Pipeline in einem anderen Projekt zu starten und kann dabei einige Konfigurationen wie Branch oder Variablen übergeben. Es gibt jedoch auch Einschränkungen hinsichtlich der Kontrolle. Beispielsweise hat die übergeordnete Pipeline keinerlei Kontrolle über den Ablauf der nachfolgenden Pipeline, kann also nicht steuern welche Jobs laufen sollen und kann somit bei Bedarf, Jobs auch nicht unterbrechen. Des Weiteren können Ressourcen wie Artefakte, Cache oder Container nicht gemeinsam verwendet werden, da sich die Pipeline in einem anderen Projekt befindet.

Wie wird die Ausführung gesteuert?

Bei der Verwendung von Downstream-Pipelines helfen die Keywords „only“ und „except“ die Ausführung der Child- bzw Multi-Project-Pipelines zu steuern. Diese beiden Schlüsselwörter werden verwendet, um Bedingungen festzulegen, unter denen bestimmte Downstream-Pipelines gestartet werden sollen. Dies ist wichtig, um Downstream-Pipelines nur bei bestimmten Ereignissen auszuführen. In der Hauptpipeline werden Child-Pipelines über das Keyword „trigger“ in Verbindung mit „include“ und „local“ ausgeführt.

Im folgenden Beispiel sieht man die Visualisierung und Implementierung einer Parent-Child-Pipeline in GitLab: 

Dieses Beispiel führt dann die Child-Pipeline „.gitlab-ci-staging.yml“ und anschließend die Pipeline „.gitlab-ci-production.yml“ im selben Repository aus, was in der grafischen Ansicht wie folgt aussieht: 

Zusammenfassung

GitLab Downstream-Pipelines bieten eine effektive Möglichkeit, um komplexe CI/CD Pipelines besser und übersichtlicher zu strukturieren. Sie ermöglichen eine klare Trennung der Aufgaben, wodurch die Wartbarkeit der Pipeline deutlich verbessert wird. 

Seminarempfehlung