Die Fab 5 für GitLab CI

Hallo! Ich arbeite seit etwa sechs Monaten mit GitLab (derzeit 11.6.10-ee) in einem Enterprise-Umfeld. Hier sind einige Tipps, bevor ihr mit GitLab CI startet.

1. Nehmt stattdessen Jenkins

GitLab hat in letzter Zeit viel Aufmerksamkeit erhalten, und ich wollte es unbedingt nutzen. Jetzt bereue ich es jedoch und wünschte, ich hätte stattdessen Jenkins gewählt.

Der CI-Engine fehlen (oder fehlten) viele Features, die ich bereits als selbstverständlich angesehen habe, etwa: Includes (eingeführt in 11.4), Laufzeitparameter für Pipelines (in 10.8) und die Begrenzung paralleler Pipelines desselben Branches auf 1 (noch in Diskussion).

Für GitLab muss ich allerdings sagen, dass es wirklich robust ist und einige gute Features bietet. Der Service docker:dind (Docker in Docker) ist beispielsweise sehr robust und lässt sich in Pipelines einfach nutzen. GitLab CI dokumentiert außerdem klar, was es kann und was nicht. Ich wünschte nur, ich hätte einen Teil dieser Dokumentation gelesen, bevor ich losgelegt habe.

2. Lasst euch die Haare richtig kurz schneiden

Die Kombination aus YAML und einem GitLab-Interpreter ist extrem frustrierend. Vielleicht denkt ihr, ihr seid auf der sicheren Seite, wenn ihr die Standard-YAML-Operatoren für mehrzeilige Inhalte |, ,|-, >, >- perfekt versteht.

Leider ist das nicht der Fall.

Die Syntax ist eine GitLab-spezifische Variante von YAML, bei der ihr euch manchmal die Haare raufen werdet.

Deshalb wünschte ich, ich hätte vor dem Start mit GitLab CI in einen richtig kurzen Haarschnitt investiert.

Kinder, versucht das nicht zu Hause

• Ein einzelner echo-Befehl mit mehrzeiliger Ausgabe

• Bash-for-Schleife über mehrere Zeilen, ohne Semikolons zu spammen

• +/- u/e in einer Bash-YAML-Vorlage setzen (.hidden_job: &gonnaignoremodes)

3. Vergesst die Zugriffskontrolle

Wenn ihr GitLab CI nutzt, seid ihr in dieser Branche eindeutig glückliche Einhörner.

Zugriffskontrolle ist etwas für Dinosaurier.

Wenn ihr jemals an Zugriffskontrolle denkt, hört auf, daran zu denken, und denkt stattdessen an etwas Großartiges.

Wenn ein Dinosaurier euch außerdem bittet, dem Enterprise-Site-Reliability-Engineering-Team (oder Ops-Team) rollenbasierten Zugriff für das Deployment von Apps nach Staging oder Produktion zu geben, macht sie zu globalen Admins. Damit werden sie zufrieden sein.

In GitLab haben Variablen genau zwei Modi. Entweder sind sie geschützt und in geschützten Branches verfügbar, oder sie sind überhaupt nicht geschützt. Das lässt sich leicht lösen, indem ihr alle Ops-Leute in Admin-Rollen hochstuft und diese Entwickler-Einhörner mit Zugriffsrechten auf Entwickler-Ebene auf Abstand haltet. Ich meine, warum sollte ein Entwickler jemals Zugriff auf den Master-Branch benötigen?

4. Vermeidet gemeinsame Deployment-Prozesse

GitLab CI erlaubt derzeit, eine Remote-YAML-Datei als Pipeline-Definition einzubinden. Ihr könnt jedoch nur eine Datei einbinden, die keine verschachtelten Includes enthält (vor Version 11.7).

Ein Include einer Remote-Datei unterstützt keine Authentifizierung. Ihr könnt YAML-Vorlagen (.) und Anker (&) definieren. Vorlagen und Anker könnt ihr jedoch nur innerhalb derselben Datei referenzieren. Mit anderen Worten: Ihr könnt keine Vorlagen oder Anker einbinden. Stattdessen müsst ihr sie in der Remote-Datei auflösen, bevor ihr diese einbindet. Und das, ohne Parameter an das Include übergeben zu können.

Das Ergebnis ist, dass ihr beispielsweise nicht zwei alternative Build-Jobs definieren könnt, aus denen der Endnutzer wählen kann, sondern nur einen.

Zusätzlich arbeitet GitLab CI mit Stages. Eine Pipeline muss Stages (Build, Test, Deployment) sowie Jobs definieren, die in diesen Stages ausgeführt werden. Wenn ihr eine Stage ohne Job definiert, stürzt die Pipeline ab. Wenn ihr einen Job definiert, der keiner Stage zugeordnet ist, stürzt die Pipeline ab.

Das könnte zum Beispiel passieren, wenn das Pipeline-Template einen Job zur Codeanalyse definiert, die Endnutzer die Stage aber nicht einbinden, weil ihr Editor dieselbe Aufgabe bereits besser erledigt.

Ein Dinosaurier könnte natürlich argumentieren, dass sie es dann verdienen, als fehlgeleitete Ketzer in der Hölle zu brennen. Ich vermute allerdings, dass wir uns da nicht alle einig sind.

Vergesst gemeinsame Pipelines oder Jobs

Wenn ihr nicht an eine Einheitsgröße glaubt, die für alle passt, dann vergesst gemeinsame Pipelines oder Jobs. Andererseits sind wir ja Microservice-Einhörner, und unsere Snowflake-Anwendungen haben keinerlei gemeinsame Schritte in ihren Pipelines – also wen kümmert's.

(Psst. Gemeinsame Release-Prozesse sind etwas für Dinosaurier.)

Workaround (falls ihr Dinosaurier seid und auf gemeinsamer Nutzung besteht)

Schreibt Code, der für jede mögliche Kombination zentraler Job-Templates eine eigene YAML-Datei erzeugt und sie in einem Artifact Storage ablegt. Die Endnutzer können dann von dort ihre bevorzugte Pipeline einbinden.

Oder nutzt sed. Sed ist immer großartig.

Nicht, dass sed etwas anderes als Code wäre. Sed ist Code. Sed ist alles.

5. Schaut Inception

Neben der Tatsache, dass Inception ein guter Film ist, vermittelt er euch die entscheidende Denkweise, um andere Tools in eure GitLab-Pipeline einzubetten.

Zum Beispiel spielt es keine Rolle, wie fehlerhaft die Includes sind, wenn ihr nur Ansible aufruft, das wiederum all eure bevorzugten Roles aus der privaten Galaxy eurer Organisation einbindet.

Alternativ könntet ihr eine Sammlung von Perl- oder Bash-Skripten haben, die ihr aus einem Artifact Storage klont. Vorausgesetzt, ihr seid Dinosaurier und vertraut keinen Einhorn-Tools wie Ansible, Octopus, Chef, Puppet oder irgendetwas, das mit Golang oder Ruby erstellt wurde.