Vom Git-Tag bis auf den Server: unsere Release-Pipeline

Ein Release von Blocks Beyond The Stars besteht heute aus einem einzigen Befehl: einen Git-Tag pushen. Alles danach macht die Maschine. In diesem Artikel zeige ich unsere CI/CD-Pipeline — und warum sich der Aufwand auch für ein Hobby-Projekt lohnt.

Der Release-Workflow. Sobald ein Tag wie v0.7.4 gepusht wird, baut GitHub Actions das komplette Paket: Windows-Installer (Setup, Portable, MSI), Linux-Build, WebGL-Build für den Browser und ein Docker-Image für den Server — sechs Artefakte aus einem Tag. Die Versionsnummer kommt dabei aus dem Tag selbst, es gibt nur eine Quelle der Wahrheit.

Der Deploy-Workflow. Ein zweiter Workflow bringt neue Versionen auf den Server. Wichtig war uns ein Production-Gate: Der Deploy läuft erst los, wenn er explizit freigegeben wurde. Kein versehentliches „oops, das war produktiv". Der Server selbst pinnt die Spielversion in einer Konfigurationsdatei — jede neu aufwachende Welt startet dann automatisch mit der neuen Version, laufende Welten werden nicht unterbrochen.

Eine Lektion, die wir lernen mussten: Fixes im Spielclient erreichen die Spieler erst mit einem echten Release. Unser Client aktualisiert sich über Velopack — wer das Spiel installiert hat, bekommt Updates nur, wenn wir eine neue Version veröffentlichen. Ein gemergter Bugfix auf dem main-Branch hilft niemandem, solange kein Tag folgt. Klingt banal, aber wir haben uns mehr als einmal gewundert, warum ein „gefixter" Bug noch da war.

Und der Browser? Der WebGL-Build wird als ZIP auf den Server gelegt und per Verzeichnis-Tausch aktiviert — das alte Verzeichnis bleibt als Fallback liegen. Eine kleine version.txt verrät, was gerade live ist.

Der ganze Apparat hat ein paar Wochenenden gekostet — und zahlt sich bei jedem Release aufs Neue aus.