gitタグからライブサーバーまで：リリースパイプライン

Blocks Beyond The Stars のリリースは、いまではコマンド1つ、gitタグをプッシュするだけです。そのあとはすべて、機械がやってくれます。この記事では、ぼくたちのCI/CDパイプラインと、趣味のプロジェクトでもその手間が報われる理由を紹介します。

リリースのワークフロー。v0.7.4 のようなタグがプッシュされると、GitHub Actionsが完全なパッケージをビルドします。Windowsのインストーラー（セットアップ、ポータブル、MSI）、Linux版、ブラウザ向けのWebGL版、サーバー用のDockerイメージ。1つのタグから、6つの成果物ができます。バージョン番号はタグそのものから取るので、情報源はひとつだけです。

デプロイのワークフロー。2つめのワークフローが、新しいバージョンをサーバーに届けます。大切にしたのは本番へのゲートです。デプロイは、はっきり承認されてからでないと始まりません。うっかり「あっ、それは本番だった」ということはありません。サーバー自身も、ゲームのバージョンを設定ファイルに固定していて、新しく目を覚ます世界はすべて自動で新バージョンで始まり、すでに動いている世界は中断されません。

学ばなければならなかった教訓：ゲームクライアントの修正は、本物のリリースでしかプレイヤーに届きません。クライアントはVelopackで自分自身を更新するので、ゲームをインストールした人は、ぼくたちが新しいバージョンを公開したときにしか更新を受け取れません。mainブランチにマージしたバグ修正は、タグが続かなければ誰の役にも立ちません。当たり前に聞こえますが、「直した」はずのバグがまだ残っているのはなぜだろう、と首をかしげたことが何度もありました。

ブラウザは？WebGL版はZIPとしてサーバーに置かれ、ディレクトリを入れ替えて有効にします。古いディレクトリは、フォールバックとして残ります。小さな version.txt を見れば、いま何が公開されているかがわかります。

この仕組み全体に、数回の週末がかかりました。そして、リリースのたびにまた元が取れていきます。