BlueLabs beschleunigt Monorepo-Builds um das Vierfache mit Semaphore

Die Herausforderung

Das Frontend-Team begann mit Experimenten in einem Monorepo. Sie litten unter fehlerhaften Releases aufgrund inkompatibler Versionen in ihrem eigenen Ökosystem. Da sie so viel Code wie möglich veröffentlichen wollten und Erfahrung im Veröffentlichen von Node-Paketen in privaten Repositories hatten, beschlossen sie, Monorepos auszuprobieren.

Das erste, was dem Team auffiel, war, dass der Build-Prozess in einem Monorepo langsamer ist. Dies fiel besonders auf, da sie die einzigen im Unternehmen mit einem Monorepo waren, und es stach in der Übersicht hervor. Daher mussten sie etwas Zeit darauf verwenden, die Pipelines zu optimieren, hauptsächlich durch das Caching von Abhängigkeiten und Artefakten sowie durch eine effizientere Nutzung von Docker.

Insgesamt benötigte BlueLabs ihre neue CI/CD-Lösung, um

• ✔️ Verstehen, was sich in einem Monorepo geändert hat
• ✔️ Die Build-Zeiten unter Kontrolle halten
• ✔️ Eine sofortige Strategie zur Speicherung von Artefakten haben
• ✔️ Einen kurzen Feedbackzyklus für geänderten Code etablieren

Die Lösung

BlueLabs‘ Monorepo hat zwei Hauptordner: apps für markenspezifische Anwendungen und packages für gemeinsam genutzten Code. Der Aha-Moment kam, als sie erkannten, dass das alleinige Ausführen von statischer Analyse und Tests in einem Paket länger dauerte als das gleichzeitige Bauen aller Pakete. Daher entschieden sie sich für einen anderen Ansatz: selektive Tests und atomare Builds.

Diese Erkenntnis, zusammen mit der Einführung eines CI-Systems, das nur den Code testet, der sich geändert hat, ermöglichte es ihnen, die Build-Zeiten um das Vierfache zu reduzieren. Unten sehen Sie einen Screenshot des neuesten Runs, bei dem nur eine kleine UI-Änderung in einem der Pakete vorgenommen wurde. Der gesamte Code wird gebaut, um die Anwendung bereitzustellen, aber Tests und statische Analysen werden nur dort durchgeführt, wo Updates vorgenommen wurden.

Das Geheimnis lag in der Einführung einer neuen change_in-Funktion, die Änderungen in den letzten Commits berechnet. Damit ist die Einrichtung bedingter Ausführungen in einem Monorepo nur noch eine Frage des Hinzufügens einer einzigen Codezeile in der Pipeline.

Die Ergebnisse

Die verbesserte Pipeline ermöglichte es BlueLabs, einen kurzen Feedbackzyklus in ihrem Entwicklungsprozess zu etablieren. Die geänderten Teile sind schneller sichtbar, der gesamte Build-Prozess ist schneller, und die Entwickler müssen nicht mehr warten, bis ihr Kaffee kalt wird, um zu erfahren, ob die Tests bestanden haben. Nicht nur die Produktivität der Entwickler hat sich verbessert, sondern BlueLabs konnte auch die Kosten für ihre CI/CD reduzieren.

Nachdem die Entwickler mehr Erfahrung mit Monorepos gesammelt hatten, konnten sie spezifischere Änderungsbedingungen festlegen und das Caching von Artefakten besser nutzen. Heute ist der Codebestand seit dem Umstieg auf Monorepo um 30 % gewachsen, und die durchschnittliche Dauer ihrer längsten Pipeline ist um das Vierfache gesenkt worden, von 17 auf nur noch 4 Minuten.

BlueLabs entwickelt und implementiert Plattformen für die Sportwettenbranche von Grund auf. Das Unternehmen arbeitet derzeit an einer End-to-End-Lösung, die Sportdaten und Ereignisse sammelt, Wetten annimmt und validiert, Ergebnisse und Auszahlungen bearbeitet und das bestmögliche Nutzererlebnis auf der Webplattform bietet.
careers.bluelabs.eu

Branche

Sportwetten

Engineering-Team

15 Personen

Technologie-Stack