Skip to content

Gitlab für Continuous Integration & Continuous Delivery

Ist Gitlab für Continuous Integration und Continuous Delivery (CI/CD) ausreichend? Das habe ich mich gefragt, als ich seit langer Zeit mal wieder ein halbwegs ernsthaftes Entwicklungsprojekt begonnen habe. Da ich keinen extra Jenkins aufsetzen wollte, habe ich mir die Funktionen von Gitlab angesehen. In diesem Sinne hier meine Meinung dazu. Disclaimer: ich muss sagen, dass ich mich nicht in epischer Breite damit befasst habe. Daher ist es eher eine Newbie-Meinung als Fachartikel.

Prinzipiell möchte ich die Software aus den Repositorys der einzelnen Komponenten

  • kompilieren,
  • die Tests ausführen,
  • ein neues Docker Image auf einer eigenen Docker Registry bereitstellen und
  • auf einem Staging-System deployen.

Funktional ist das für Gitlab kein Problem. Bis auf den letzten Punkt. Ein wenig.

Positiv

Was ich allgemein gut finde ist, sich Alles in demselben System befindet. Alles ist in einer Oberfläche, es gibt nur einen Login, die Repository und Build Informationen sind im UI miteinander verknüpft. Das ist doch viel einfacher zu handhaben als ich das sonst kenne. So habe ich mir das vorgestellt.

Das System verwendet Docker Images als Buildumgebung. Das ist vorteilhaft, denn man muss auf dem System nicht erst die Build-Tools (wie Maven, Java, npm, etc.) installieren, sondern kann entsprechende Images nutzen. Ein SSH-Login auf das Buildsystem oder die Worker-Nodes ist damit nicht notwendig, alles geht per Konfiguration im Git. (Zumindest, wenn die Kubernetes Nodes von jemanden eingerichtet werden.)

Negativ

Zur Konfiguration der Build Jobs (gitlab Pipelines) wird eine YAML Datei im Repository angelegt. In der Datei werden in entsprechenden Abschnitte die Build-Umgebung und die Build-Befehle angegeben. Ich finde da sehr unpraktisch. Ich will mich eigentlich nicht mit dem Befehlen und der Syntax für das Buildsystems beschäftigen, sondern einfach die Aufgabe einrichten. So ist es in etwa, als wenn ich Kunden im CRM per SQL Statement anlege. Eine dialogbasierte UI wäre um einiges angenehmer. Die Doku zu durchwühlen ist da doch um einiges aufwändiger als es sein müsste.

Für einzelne Repositorys kann man die Pipelines konfigurieren und wie oben gesagt, alle Schritte umsetzen. Ich habe jedoch keine Möglichkeit gesehen, abhängige Projekte zu bauen. Wenn ich also einen Service habe, der eine API für ein Frontend anbietet, dann möchte ich, bevor ich den Service auf eine Live Umgebung deploye, zunächst die Integration Tests des Frontends ausführen um zu sehen, ob alles läuft. Solche Abhängigkeiten oder auch Continuous Delivery Pipelines konnte ich nicht konfigurieren. Vielleicht habe ich aber auch nicht tief genug in die Dokumentation der YAML Files geschaut.

Fazit

Man kann Continuos Integration mit Gitlab machen, wenn man auf Config-Files steht. Für größere Projekte und Continuous Delivery hilft mir persönlich das System so erstmal nicht weiter. Da nutze ich doch lieber eine der Alternativen.

Hat jemand andere Erfahrungen?

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.