От git-тега до живого сервера: наш конвейер релизов

Релиз Blocks Beyond The Stars сегодня сводится к одной команде: отправить git-тег. Всё остальное делает машина. В этой статье я покажу наш конвейер CI/CD — и почему усилия окупаются даже в хобби-проекте.

Релизный рабочий процесс. Как только отправлен тег вроде v0.7.4, GitHub Actions собирает полный пакет: установщики для Windows (setup, portable, MSI), сборку для Linux, сборку WebGL для браузера и образ Docker для сервера — шесть артефактов из одного тега. Номер версии берётся из самого тега; источник правды только один.

Рабочий процесс развёртывания. Второй процесс доставляет новые версии на сервер. Для нас было важно иметь производственные ворота: развёртывание начинается только после явного подтверждения. Никаких случайных «ой, это был прод». Сам сервер закрепляет версию игры в конфигурационном файле — каждый вновь пробуждённый мир автоматически стартует с новой версией, а работающие миры остаются нетронутыми.

Урок, который нам пришлось усвоить: исправления в клиенте игры доходят до игроков только с настоящим релизом. Наш клиент обновляется сам через Velopack — тот, кто установил игру, получает обновления, только когда мы публикуем новую версию. Влитое исправление в главной ветке никому не поможет, пока за ним не последует тег. Звучит очевидно, но не раз мы удивлялись, почему «исправленный» баг всё ещё на месте.

А что с браузером? Сборка WebGL кладётся на сервер как ZIP и активируется заменой каталога — старый каталог остаётся как запасной. Маленький файл version.txt показывает, что сейчас в работе.

Весь этот аппарат стоил нам нескольких выходных — и окупается снова с каждым релизом.