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?

The post Gitlab für Continuous Integration & Continuous Delivery appeared first on Patrick Steinert.

What have I done:

• Kicked of the first quarter 2016 with hard deadlines for Cloud of Things (watch out for CeBIT)
• Had some weekend & night shifts because of service outages of Cloud of Things. Turned out that a Gelf4J appender for Graylog caused the issues.
• Started to play with JavaFX and build a Cloud of Things Genius Client for testing purposes on CoT. (Thanks code.makery for this helpful JavaFX tutorial)
• Did a talk on our Deutsche Telekom M2M Day 2016
• I have a new record on contributing to Github

Read:

• MQTT Security Fundamentals: MQTT Payload Encryption
• Why Big Companies Keep Failing: The Stack Fallacy
• The evils of chasing Scrum Velocity…

PS: A new try to give a regular update on this blog. Last year I tried a weekly recap, didn’t worked out. But I’m pretty sure that this will work ;-)

The post Retrospective January 2016 appeared first on Patrick Steinert.