Van git-tag naar live server: onze releasepijplijn

Een release van Blocks Beyond The Stars bestaat vandaag uit één commando: een git-tag pushen. Alles daarna doet de machine. In dit artikel laat ik onze CI/CD-pijplijn zien — en waarom de moeite zich zelfs voor een hobbyproject loont.

De releaseworkflow. Zodra een tag zoals v0.7.4 is gepusht, bouwt GitHub Actions het complete pakket: Windows-installers (setup, portable, MSI), een Linux-build, een WebGL-build voor de browser en een Docker-image voor de server — zes artefacten uit één tag. Het versienummer komt uit de tag zelf; er is maar één bron van waarheid.

De deployworkflow. Een tweede workflow brengt nieuwe versies naar de server. Wat voor ons telde was een productiepoort: de deploy start pas als hij expliciet is goedgekeurd. Geen onbedoeld “oeps, dat was productie”. De server zelf legt de spelversie vast in een configuratiebestand — elke nieuw wakker wordende wereld start dan automatisch met de nieuwe versie, terwijl draaiende werelden ongestoord doorgaan.

Een les die we moesten leren: fixes in de gameclient bereiken de spelers pas met een echte release. Onze client werkt zichzelf bij via Velopack — wie het spel heeft geïnstalleerd, krijgt alleen updates als wij een nieuwe versie publiceren. Een gemergde bugfix op de hoofdbranch helpt niemand zolang er geen tag volgt. Klinkt vanzelfsprekend, maar meer dan eens vroegen we ons af waarom een “gefixte” bug er nog was.

En de browser? De WebGL-build wordt als ZIP op de server gezet en geactiveerd via een mapwissel — de oude map blijft als terugval staan. Een klein version.txt verraadt wat er nu live staat.

Het hele apparaat kostte een paar weekenden — en verdient zichzelf met elke release opnieuw terug.