Innerhalb einer Pipeline wird es immer Jobs geben, die auf andere aufbauen oder von denen Abhängig sind. Das ganze zu modellieren kann sehr schwierig sein. Gibtlab bietet uns die Möglichkeit das ganze etwas einfacher zu machen mit bestimmte Keywords in unserer Definition. Wir schauen uns das ganze hier einmal genauer an. Wichtig hier ist, dass wir eine Pipeline bauen mit Bauen der Binary, Testing und Validation und anschließend dem Deployen von dieser. Wir definieren uns die Jobs aber nicht, sondern arbeiten mit einer Ausgabe in dem Job. Mit den richtigen Jobs würde das ganze zu ausarten und zu komplex werden.
Um die Reihenfolge zu bestimmen haben wir in Gitlab mehrere Möglichkeiten. Zum einen können wir das Schlüsselwort needs oder das Schlüsselwort dependencies verwenden. Hier erst einmal die Unterschiede:
| Schlüsselwort | Bedeutung |
|---|---|
| dependencies | Gibt an welche Artifakte benötigt werden ohne die Reihenfolge zu ändern |
| needs | Gibt an in welcher Reihenfolge die Ausführung erfolgt und die Artifakte gedownloadet werden |
| needs:artifacts | Gibt an in welcher Reihenfolge die Ausführung erfolgt ohne die Artifakte zu downloaden |
| zuweisung per Stage | Standardmäßig laufen die Stages nacheinander und alles was innerhalb einer Stage ist parallel |
Wir starten mit dem Festlegen der verschiedenen Stages. Dabei habe ich oben schon ausgeführt was wir machen wollen.
Da die Validierung ruhig neben dem Testen laufen kann aber manche Jobs doch ggf. eine Abhängigkeit dazu haben teilen wir diese zwei Stages auf und starten mal mit folgendem Gerüst:
1stages:
2 - build
3 - testing
4 - validate
5 - deploy
die definition unserer Stages
In der Build Stage haben wir keine Abhängigkeiten und können daher einfach unsere Jobs dahin schreiben.
1build_binary:
2 stage: build
3 script: echo from Build
4
5build_docker:
6 stage: build
7 script: echo from Build
In der Testing stage gibt es die Abhängigkeit, dass wir definitiv vorher ein Binary brauchen. Wir legen uns also für jeden Test, den wir machen wollen einen Job an.
Wir definieren einfach mal folgende Tests, die wir unterbringen wollen.
Hier haben wir die Möglichkeit unsere Unit-Tests von dem Build Abhängig zu machen, so dass wir zuerst eine Binary haben. Wir schreiben also zuerst wieder unsere leeren Jobs und weisen Sie der testing Stage zu.
1app_tests:
2 stage: testing
3 script: echo from testing
4 needs:
5 - build_binary
6
7dependency_tests:
8 stage: testing
9 script: echo from testing
wir können bei einem Job einfach ein
needsanfügen und als Array dann alle Jobs die vorher gelaufen sein müssen angeben
Die Validierungs Stage bietet uns die Möglichkeit die Anwendung nochmal auf Schwachstellen zu prüfen. Wir definieren hier folgende Jobs
Die Validation Stage wird jetzt etwas spannender. Hier definieren wir aber zuerst die leeren Jobs einmal:
1container_scans:
2 stage: validate
3 script: echo from validation
4
5vulnerable_scans:
6 stage: validate
7 script: echo from validation
8
9sonarCube:
10 stage: validate
11 script: echo from validation
Anschließend überlegen fügen wir die needs Parameter hinzu. Zuerst beim Container Scanning. Um einen Container zu scannen brauchen wir natürlich erst einmal einen. Daher haben wir dazu schon mal eine Abhängigkeit. Bei den vulerable_scans würde ich eine Abhängigkeit zu den neueren Versionen machen, da es uns nicht unbedingt was bringt wenn es keinen Fix dafür gibt. Bei Sonar haben wir die Beziehung zu den App Tests, da diese auch auf die Coverage geprüft werden in dem Programm.
1container_scans:
2 stage: validation
3 script: echo from validation
4 needs:
5 - build_docker
6
7vulnerable_scans:
8 stage: validation
9 script: echo from validation
10 needs:
11 - dependency_tests
12
13
14sonarCube:
15 stage: validation
16 script: echo from validation
17 needs:
18 - app_tests
alle Jobs haben hier eine Abhägngkeit. Es können aber auch für einen Job mehrere definiert werden
Für das Deployment möchten wir gerne einen guten Stand. Das heißt wir möchten, dass alle Tests grün sind vorher gelaufen und das die Container Scans keine Schwachstellen zeigen. Wir schreiben also hier auch ein needs für die zwei Jobs. Wichtig zu wissen ist, dass es in gitlab-CI nur in die nächste Stage geht, wenn die vorherige Grün ist. Wir müssten hier also eigentlich keine needs schreiben, da gitlab das ganz von alleine schon tun würde.
1deploy:
2 stage: deploy
3 script: echo from deploy
4 needs:
5 - dependency_tests
6 - container_scans
7 - app_tests
Die ganze Pipeline sieht nun in der Übersicht wie folgt aus.
Diese Grafik zeigt die Übersicht über eine Pipeline. Unter Build > Pipelines kann man sich die einzelnen Runs anzeigen lassen und diese Übersicht aufrufen.