Starten und Visualisieren von Pipelines bei der Konfiguration von GitLab CI / CD für mehrere Projekte.
Continuous Integration (CI) ist die Praxis der Automatisierung des Zusammenstellens und Testens von Code, bevor dieser mit dem Hauptzweig zusammengeführt wird. Entwickler können Code häufig und frühzeitig einfügen und gleichzeitig das Risiko verringern, dass neue Fehler in das Haupt-Quellcode-Repository eingefügt werden.
Obwohl CI prüft, ob der neue Code nicht beschädigt wird, wenn er in anderen Code im selben Repo integriert wird, ist das Bestehen aller Tests für dieses Repo nur der erste Schritt. Nach dem Ausführen von CI in Code ist es wichtig, Tests in einer realen Umgebung bereitzustellen und auszuführen. Der Übergang von CI zu Continuous Delivery and Deployment (CD) ist der nächste Schritt zu den "erwachsenen" DevOps. Durch die Bereitstellung und anschließende erneute Prüfung können Sie den Code eines Projekts zusammen mit anderen Komponenten und Diensten testen, die möglicherweise von anderen Projekten verwaltet werden.
Warum muss ich sicherstellen, dass mein Code mit anderen Komponenten funktioniert?
Ein gutes Beispiel ist die Architektur von Microservices. In der Regel werden Microservices in verschiedenen Projekten verwaltet , wobei jeder Microservice über ein eigenes Repository mit einer Pipeline verfügt. Darüber hinaus ist sehr oft jedes Entwicklungsteam für individuelle Microservices und Pipeline-Konfigurationen verantwortlich. Als Programmierer möchten Sie möglicherweise sicherstellen, dass Änderungen an Ihrem Code nicht die Funktionalität seiner Microservices verletzen. Daher können Sie zusätzlich zu den Tests für Ihr Projekt auch Tests für sie ausführen.
Pipeline Cross Projekt
Wenn Sie eine Projektpipeline starten, müssen Sie auch eine projektübergreifende Pipeline ausführen, die schließlich die neueste Version aller abhängigen Microservices bereitstellt und testet. Um dies zu erreichen, benötigen Sie eine einfache, flexible und bequeme Möglichkeit, andere Pipelines im Rahmen des CI Ihres Projekts zu starten. GitLab CI / CD bietet eine einfache Möglichkeit, eine projektübergreifende Pipeline zu starten, indem der CI-Konfigurationsdatei eine spezielle Aufgabe hinzugefügt wird.
GitLab CI / CD-Konfigurationsdatei
In GitLab CI / CD werden Pipelines sowie Jobs und die Schritte ihrer Komponenten in der .gitlab-ci.yml für jedes Projekt definiert. Die Datei ist Teil des Projekt-Repositorys. Es ist vollständig versioniert und kann von Entwicklern mit einer beliebigen IDE ihrer Wahl bearbeitet werden. Sie müssen weder den Systemadministrator noch den DevOps-Befehl auffordern, Änderungen an der Pipeline-Konfiguration vorzunehmen, da sie dies selbst tun können. Die .gitlab-ci.yml bestimmt die Struktur und Reihenfolge der Pipelines und entscheidet, was mit dem GitLab Runner (dem Agenten, der die Aufgaben .gitlab-ci.yml ) ausgeführt werden muss und welche Entscheidungen getroffen werden sollten, wenn bestimmte Bedingungen auftreten, z. B. wenn der Prozess erfolgreich abgeschlossen oder beendet wird System.
Hinzufügen eines Jobs zum Ausführen einer projektübergreifenden Pipeline
Ab GitLab 11.8 bietet GitLab eine neue CI / CD-Konfigurationssyntax zum Ausführen projektübergreifender Pipelines, die in den Pipline-Konfigurationsregeln enthalten ist . Der folgende Code veranschaulicht das Konfigurieren eines Bridge-Jobs zum Ausführen einer Downlink-Pipeline:
// job1 job deploy: stage: Deploy script: this is my script // job2 bridge job , - Android: stage: Trigger-cross-projects trigger: mobile/android
Im obigen Beispiel wird die Aufgabe für Android Bridge gestartet, sobald der Bereitstellungsjob in der Bereitstellungsphase erfolgreich ist. Der ursprüngliche Status steht noch aus. GitLab erstellt eine Downstream-Pipeline im Mobile / Android-Projekt. Sobald diese erstellt wurde, ist der Android-Job erfolgreich. In diesem Fall ist Mobile / Android der vollständige Pfad zu diesem Projekt.
Der Benutzer, der die Upstream-Pipeline erstellt hat, muss über Zugriffsrechte für das Downstream-Projekt verfügen (in diesem Fall für Mobile / Android). Wenn das nachgelagerte Projekt nicht gefunden werden kann oder der Benutzer keine Zugriffsrechte zum Erstellen einer Pipeline hat, erhält der Android-Job den Status "Fehlgeschlagen".
Übersicht der Diagramme von der Upstream- zur Downstream-Pipeline
Mit GitLab CI / CD können Sie die Pipeline-Konfiguration visualisieren. In der folgenden Abbildung sind die Schritte zum Zusammenbau, Testen und Bereitstellen Teil eines vorgelagerten Projekts. Sobald der Bereitstellungsjob erfolgreich abgeschlossen wurde, werden vier projektübergreifende Projekte parallel gestartet, und Sie können mit ihnen fortfahren, indem Sie auf einen der nachgelagerten Jobs klicken.
In der Abbildung unten sehen Sie die absteigende Gewinnlinie „Service - Finanzen“. Jetzt können Sie nach links zur aufsteigenden Pipeline scrollen, nach rechts zurück zur absteigenden Pipeline scrollen oder eine andere absteigende Pipeline auswählen.
Definieren eines untergeordneten Pipeline-Zweigs
Sie können den Namen des Zweigs angeben, den die absteigende Pipeline verwenden soll:
trigger: project: mobile/android branch: stable-11-2
Verwenden Sie das Schlüsselwort project, um den vollständigen Pfad zum nachgelagerten Projekt anzugeben. Verwenden Sie das Schlüsselwort branch, um den Namen des Zweigs zu bestimmen. GitLab verwendet beim Erstellen der Downlink-Pipeline das Commit, das sich derzeit im HEAD-Zweig befindet.
Übergeben von Variablen an eine absteigende Pipeline
Eines Tages möchten Sie möglicherweise Variablen an eine absteigende Pipeline übergeben. Sie können dies mit Schlüsselwörtern für Variablen tun, wie Sie es bei einer regulären Jobdefinition tun würden.
Android: variable: ENVIRONMENT: 'This is the variable value for the downstream pipeline' stage: Trigger-cross-projects trigger: mobile/android
Die Variable ENVIRONMENT wird an jeden in der absteigenden Pipeline definierten Job übergeben. Es ist jedes Mal als Umgebungsvariable verfügbar, wenn GitLab Runner einen Job auswählt.
Projektübergreifende Gesamtpipeline
Die .gitlab-ci.yml bestimmt die Reihenfolge der CI / CD-Stufen, welche Aufgaben ausgeführt werden sollen und unter welchen Bedingungen die Aufgabe gestartet oder übersprungen werden soll. Durch Hinzufügen eines 'Bridge-Jobs' mit dem Schlüsselwort trigger zu dieser Datei können projektübergreifende Pipelines ausgeführt werden. Wir können Parameter an Jobs in absteigenden Pipelines übergeben und sogar den Zweig definieren, den die absteigende Pipeline verwenden wird.
Pipelines können komplexe Strukturen mit vielen sequentiellen und parallelen Aufgaben sein, und wie wir gerade erfahren haben, können sie manchmal nachgeschaltete Pipelines ausführen. Um das Verständnis des Pipeline-Flusses einschließlich der nachgeschalteten Pipelines zu vereinfachen, verfügt GitLab über Pipline-Grafiken zum Anzeigen von Pipelines und deren Status.
Lesen Sie auch andere Artikel in unserem Blog: