Wie Kiwi.com seinen Workflow mit GitLab und Docker grundlegend erneuert hat

Kiwi.com ist ein Online-Travel-Tech-Unternehmen, das Reiserouten für Kunden weltweit anbietet. Der proprietäre Algorithmus Virtual Interlining ermöglicht es Nutzenden, Flüge und Bodentransport von mehr als 800 Anbietern zu kombinieren – einschließlich vieler, die normalerweise nicht an gemeinsamen Angeboten teilnehmen. Alle Verbindungen sind durch die Kiwi.com Guarantee abgesichert, die Kunden vor verpassten Anschlüssen durch Verspätungen, Zeitplanänderungen oder Stornierungen schützt.

Nach der Startup-Phase begann Kiwi.com, seine Systeme zu vereinheitlichen. Erstens gab es keine Konsistenz darin, wie verschiedene Teams ihre Dienste deployen – hauptsächlich weil Docker kein fester Bestandteil des Workflows war. Zweitens waren die historischen Informationen zur Softwareentwicklung in isolierten Silos ohne ausreichende Dokumentation.

Kiwi.com hatte weder Continuous Integration noch Delivery-Systeme im Einsatz. „Der Release-Prozess war langwierig, und selbst ein Rollback war keine einfache Aufgabe. Alles wurde manuell erledigt", sagt Alex Viscreanu, Technical Team Lead bei Kiwi.com. „Es gab überhaupt keine Automatisierung."

Das Entwicklungsteam arbeitete zunächst mit verschiedenen Softwareplattformen, fand aber, dass das Ausführen von Shell-Befehlen keine gute Erfahrung war. Keine der Lösungen bot ausreichende Container-Unterstützung – ein zentrales Anforderungskriterium. Nach dem Test von GitLab erkannte das Team, dass es die am besten integrierte Plattform bot. „Als wir GitLab ausprobiert haben und gesehen haben, wie gut CI/CD mit allem integriert ist und dass wir CI/CD für automatisches Mergen von Code nutzen und unseren Checks vertrauen können, ohne uns um alles Mögliche zu sorgen – das war für uns sofort klar", erklärt Viscreanu.

Das erste große Problem, das GitLab löste, war die einfache Integration mit Docker, die es dem Team ermöglichte, Container als primäre Art zur Paketierung von Software zu nutzen. Zuvor hatte das Team nicht mit Containern gearbeitet – mit GitLab CI begannen sie, sie überall einzusetzen. „Sobald das an Ort und Stelle war und wir eine einfache Möglichkeit hatten, Code zu prüfen und Deployments zu automatisieren, war alles so gut integriert, dass wir Aktionen direkt aus GitLab heraus auslösen konnten", sagt Viscreanu. „Aktuell haben wir automatisiertes Deployment, automatisierte Dependency-Pflege, automatisiertes Dependency-Scanning, automatisiertes Lizenz-Scanning – automatisiert alles." Mit GitLabs Automatisierung erreicht Kiwi.com nun im Durchschnitt:

• 4.000 Commits pro Tag - 1.500 Deployments pro Monat - 47.000 Tests pro Monat - 5.000 MRs pro Monat Als Container im Unternehmen fest etabliert waren, durchlief Kiwi.com verschiedene Container-Plattformen, die die Skalierbarkeit ihrer Dienste zunehmend einschränkten. Nach diesen Erfahrungen wollte das Team nicht weiter in Produkte investieren, die nicht weiter entwickelt oder relevant bleiben würden. Entwickler suchten nach einer Lösung, die ihre Ressourcen konsistent verwaltet und den Aufbau eigener Werkzeuge ermöglicht. Der Hauptgrund dafür, so Viscreanu: „Vernunft. Es gibt keine Möglichkeit, den Überblick über all diese Werkzeuge zu behalten, wenn man ein großes Unternehmen ist, ohne sie zu automatisieren und zu vereinheitlichen."

Die Integration von GitLab mit Kubernetes hat die Arbeit deutlich vereinfacht – vor allem durch die gute Integration mit dem Rest der Lösung. Viscreanu und sein Team betreiben auch intensiv Infrastructure as Code mit Terraform in GitLab CI. Das ermöglicht es ihnen, Infrastrukturkomponenten zu deployen, zu erstellen, zu ändern und zu verwalten, ohne dies manuell tun zu müssen. „Wenn es nicht in CI ist und nicht in GitLab, dann sollten Änderungen nicht vorgenommen werden", ergänzt Viscreanu.

Alles in CI zu halten bedeutet, eine Aufzeichnung aller Änderungen zu haben und eine einzige Quelle der Wahrheit zu schaffen. „Am Anfang war CI/CD das Hauptmerkmal, und ich glaube, dass es auch jetzt noch das Merkmal ist, das wir am meisten schätzen. Wir nutzen Git als Single Source of Truth, was uns ermöglicht, zu verhindern, dass alles verteilt und von den Teams selbst verwaltet und irgendwie vergessen wird", sagt Viscreanu.

Vor GitLab war der Deployment-Prozess langsam, weil keine Gewissheit bestand, dass der gepushte Code funktioniert. Nun gilt: „Auch wenn wir nicht alles abfangen, vertrauen wir CI zumindest für die kritischen Pfade. Und mit CD und Ansätzen wie Rolling Releases können wir, selbst wenn ein Release Probleme hat, schnell reagieren, bevor alle Kunden betroffen sind", so Viscreanu.