Continuous Deployment Pipeline mit Gitlab

Automatisiertes deployment auf verschiedene Umgebungen (meist DEV, TEST, PROD) ist ein essentieller Bestandteil eines funktionierenden Entwicklungsprozesses und mittlerweile auch alles andere als Rocket Science. Und trotzdem ist der initiale Aufbau dann doch mühseliger als erwartet. Wie immer kommt es auf Details an, die es dann doch mitunter spannender machen.

Staging bedingt Parametrisierung

URLs, Zugangsdaten, IDs, ... in Applikationen haben wir laufend mit Daten zu tun, die mit der jeweiligen Umgebung abgestimmt sein müssen. Erst bei der Einführung von Staging merkt man eigentlich, wie viele dieser Konstanten dann doch nicht ganz so konstant sind, wie anfangs gedacht und somit pro Umgebung parametrisiert werden müssen.

Unsere Applikation ist mit Jira integriert und liest bzw. manipuliert Eigenschaften (darunter natürlich auch Custom Fields) von Tickets über die Jira eigene REST-API. Custom Fields haben eindeutige IDs, soweit so einfach. Damit unser Staging durchgehend funktioniert gibt es natürlich auch eine eigene Jira Instanz in unserer Testumgebung, initial eine Kopie der Produktion - die IDs aller Custom Fields sind somit über die Umgebungen hinweg ident. Und dann die Überraschung: ein neues Custom Field in Produktion bekommt eine andere ID als in der Testumgebung, und schon haben wir ein weiterer Parameter.

Wie wird eigentlich parametrisiert?

... das kommt drauf an: üblich ist eine Mischung aus Command Line Parameter und Umgebungsvariablen. Command Line Parameter ermöglichen es schnell und einfach der Applikation zum Startzeitpunkt neue, auf die Umgebung abgestimmte, Werte mitzugeben. Gerade bei Applikationen, die oft mit verschiedenen Werten durch einen Benutzer gestartet werden, macht diese Methode durchaus Sinn. Alternativ werden Werte aus den Umgebungsvariablen herausgelesen (die zuvor natürlich auch gesetzt werden müssen). Das passiert oft über den Umweg mit .env Dateien: darin sind ganz einfache Key=Value Paare hinterlegt, die mittels passendem Framework beim Start der Applikation automatisiert gelesen und als Umgebungsvariable gesetzt werden. Dieses System erlaubt auch ganz einfach eine .env Datei pro Umgebung zu verwalten: .env.test oder .env.prod usw. Aber Achtung: niemals dürfen Zugangsdaten in diesen Dateien hinterlegt werden, die dann letztendlich im Versionierungssystem landen! Auch wenn z.B. der Git Server selbst gehostet wird, sollte man diese Regel grundsätzlich befolgen.

Wir selbst setzen ausschließlich auf Umgebungsvariablen. Unser UI Framework Vue.js bringt das Management von Umgebungen über den „--mode“ Schalter bereits mit, serverseitig verwenden wir dafür die „custom-env“ Library.

^{SEQIS: Einfaches .env File für unsere lokale DEV Umgebung}

Staging bedingt Releasemanagement

Eigentlich ist Releasemanagement ja auch schon bei nur einer Umgebung, der Produktion, notwendig: es muss sichergestellt werden, dass die richtige Version jeder Applikation verfügbar ist, damit die korrekte Kommunikation gewährleistet ist. Es soll ja nicht passieren, dass Applikation A plötzlich nicht mehr mit Applikation B reden kann, weil B die API geändert hat und A nicht mitgezogen ist. Releasemanagement ist in der Produktion schon nicht trivial, in den Umgebungen davor (DEV, TEST) noch deutlich schwieriger: das Deployment-Intervall ist deutlich kürzer und die Gefahr von Inkompatibilitäten zwischen Applikation sehr hoch. Desto komplexer die Architektur (Stichwort MicroServices) und verteilter die Entwicklung (Stichwort Outsourcing) desto aufwändiger und auch wichtiger ist ein ernsthaft gelebtes Releasemanagement, sonst endet man, bildlich gesprochen, im Turmbau von Babylon.

In unserem aktuellen Projekt haben wir nur vier Teil-Applikation, von denen drei von uns direkt betreut und verantwortet werden. Dementsprechend leichtgewichtig gestaltet sich auch unser Releasemanagement: im Wesentlichen organisieren wir den Fortschritt über Jira Tickets, die über Verlinkungen die Abhängigkeiten verdeutlichen. So haben wir im Blick, was wann wo deployed sein muss, damit die Applikation als Ganzes richtig funktioniert.

Deployment @ razzfazz.io

Technologisch setzen wir generell auf Node.js und Vue.js. Das Backend bedingt eine laufende Node.js Applikation, das Frontend kann einfach von jedem beliebigen Web-Server ausgeliefert werden. Als Backend Server haben wir uns für das Service von Heroku (https://www.heroku.com) entschieden: die Heroku Runtime ermöglicht es sehr einfach Applikationen in unterschiedlichsten Technologien zu hosten, in der Minimalausführung sogar for free. Automatisiert wird alles über Gitlab CI/CD.

^{SEQIS GmbH}

Build mit Gitlab CI/CD

Gitlab selbst stellt einen Continuous Integration Service zur Verfügung, das über das .gitlab-ci.yml File konfiguriert wird. Damit steuern wird den Build, den Test und das Deployment in die jeweilige Umgebung: unser „master“ branch wird auf die PROD Umgebung deployed, „staging“ auf die TEST. Davor werden natürlich alle Tests durchgeführt und die Testabdeckung berechnet.

^{Bild:SEQIS GmbH}

Auch hier kommen wieder die Umgebungsvariablen ins Spiel, in Gitlab „Variables“. Damit kann die Applikation zur Build Time parametrisiert werden. Nach dem Deployment wird der aktuelle Code-Stand im SCM noch getagged und ein Release erstellt. Das alles passiert komplett automatisiert und wird per push in den jeweiligen Branch angestoßen. Hier noch ein Tipp: vor dem push nach „master“ oder „staging“ werden lokal, mit husky automatisiert, alle Tests durchgeführt. Das hat uns schon oft vor fehlgeschlagenen Builds bewahrt.

Server @ Heroku

Heroku unterstützt diverse automatisierte Deployment Varianten: anfangs haben wir noch manuell den aktuellen Stand in den „master“ branch des Heroku eigenen Git Repositories gepusht, aktuell verwenden wir das Deployment „Tool“ Dpl (https://github.com/travis-ci/dpl). Dpl abstrahiert Deploymenteigenheiten diverser Hosting Anbieter (uA. natürlich AWS, GAE, OpenShift, ...) und reduziert die Komplexität auf einen einzigen einfachen command line Aufruf von Dpl. Im Hintergrund verwendet Dpl die Heroku eigene REST API um die Applikation zu stoppen, den aktualisierten Stand der Applikation hochzuladen und danach die Applikation wieder zu starten. Dabei wartet Dpl den Start bis zu Ende ab und verifiziert den Status (pending, succeeded, failed), so kann man sich sicher sein, dass die Applikation auch tatsächlich korrekt gestartet werden konnte.

Für die umgebungsabhängigen Eigenschaften gib es in Heroku die so genannten „Config Vars“, die als Umgebungsvariablen der Applikation zur Verfügung gestellt werden. Damit lässt sich das für uns notwendige Staging Konzept einfach umsetzen. Nach dem Deployment ist die App unter „https://appname.herokuapp.com“ verfügbar. Angenehm ist auch das automatische SSL Certificate handling: Heroku erstellt automatisch Let‘s Encrypt Zertifikate für die jeweilige APP, terminiert die SSL Session und leitet den traffic dann unverschlüsselt an die Applikation weiter. In der Applikation selbst muss man sich dadurch mit https oder Zertifikaten gar nicht mehr herumschlagen.

Client @ SSD Webhosting

Für unseren Web-Client mit Vue.js verwenden wir unseren bereits vorhandenen Webhosting Provider SSD-Webhosting, der liefert alle statischen Ressourcen an den Browser aus. Ein Application Server ist nicht notwendig. Das erleichtert das Deployment und wir können am Ende des Gitlab Builds den aktuellen Stand einfach per SFTP auf den Server kopieren, mehr ist für ein Client Deployment nicht notwendig.

So sieht (etwas vereinfacht) unser Development/Staging Workflow im Detail aus:

^{SEQIS GmbH}

Wrap Up

Ein automatisiertes Deployment ist heutzutage tatsächlich nichts mehr Besonderes: in allen (modernen) Technologien gibt es dafür breite Unterstützung mit Tools und Frameworks, und das für kein bis wenig Geld. Wir haben anfangs Build und Deployment noch von Hand gemacht, und ja, natürlich geht das auch. Der Aufwand hielt sich auch tatsächlich in Grenzen und Fehler sind dabei auch kaum passiert. Und trotzdem ist der Schritt zur Automation ein wichtiger und richtiger gewesen.

... und ganz ehrlich: ich freu mich jedes Mal wieder, wenn ein Deployment in die Produktion genau nur ein Knopfdruck ist!