From Git Tag to Live Server: Our Release Pipeline

A release of Blocks Beyond The Stars today consists of a single command: pushing a git tag. Everything after that is done by the machine. In this article I'll show our CI/CD pipeline — and why the effort pays off even for a hobby project.

The release workflow. As soon as a tag like v0.7.4 is pushed, GitHub Actions builds the complete package: Windows installers (setup, portable, MSI), a Linux build, a WebGL build for the browser, and a Docker image for the server — six artifacts from one tag. The version number comes from the tag itself; there is only one source of truth.

The deploy workflow. A second workflow brings new versions onto the server. What mattered to us was a production gate: the deploy only starts once it has been explicitly approved. No accidental "oops, that was production". The server itself pins the game version in a configuration file — every newly waking world then automatically starts with the new version, while running worlds are left uninterrupted.

A lesson we had to learn: Fixes in the game client only reach the players with a real release. Our client updates itself via Velopack — anyone who has installed the game only gets updates when we publish a new version. A merged bugfix on the main branch helps nobody as long as no tag follows. Sounds obvious, but more than once we wondered why a "fixed" bug was still there.

And the browser? The WebGL build is dropped onto the server as a ZIP and activated via a directory swap — the old directory stays around as a fallback. A small version.txt reveals what's currently live.

The whole apparatus cost a few weekends — and pays for itself all over again with every release.