Od taga Git do działającego serwera: nasz potok wydań

Wydanie Blocks Beyond The Stars to dziś jedno polecenie: wypchnięcie taga git. Wszystko po tym robi maszyna. W tym artykule pokażę nasz potok CI/CD — i dlaczego wysiłek się opłaca nawet w hobbystycznym projekcie.

Workflow wydania. Gdy tylko tag taki jak v0.7.4 zostanie wypchnięty, GitHub Actions buduje kompletny pakiet: instalatory Windows (setup, portable, MSI), wersję na Linux, wersję WebGL dla przeglądarki i obraz Dockera dla serwera — sześć artefaktów z jednego taga. Numer wersji pochodzi z samego taga; jest tylko jedno źródło prawdy.

Workflow wdrożenia. Drugi workflow przenosi nowe wersje na serwer. Zależało nam na bramce produkcyjnej: wdrożenie rusza dopiero po wyraźnym zatwierdzeniu. Żadnego przypadkowego „ups, to była produkcja”. Sam serwer przypina wersję gry w pliku konfiguracyjnym — każdy nowo budzony świat startuje wtedy automatycznie z nową wersją, a działające światy zostają nieprzerwane.

Lekcja, którą musieliśmy odrobić: Poprawki w kliencie gry docierają do graczy dopiero z prawdziwym wydaniem. Nasz klient aktualizuje się sam przez Velopack — kto zainstalował grę, dostaje aktualizacje dopiero, gdy opublikujemy nową wersję. Scalona poprawka na głównej gałęzi nikomu nie pomoże, dopóki nie pojawi się tag. Brzmi oczywiście, ale nie raz zastanawialiśmy się, czemu „naprawiony” błąd wciąż jest.

A przeglądarka? Wersja WebGL trafia na serwer jako ZIP i jest aktywowana przez zamianę katalogów — stary katalog zostaje jako rezerwa. Mały plik version.txt zdradza, co jest aktualnie na żywo.

Cały ten aparat kosztował kilka weekendów — i przy każdym wydaniu zwraca się na nowo.