Du tag Git au serveur en ligne : notre pipeline de release

Aujourd'hui, une release de Blocks Beyond the Stars tient en une seule commande : pousser un tag Git. Tout le reste, c'est la machine qui s'en charge. Dans cet article, je présente notre pipeline CI/CD – et j'explique pourquoi l'effort en vaut la peine, même pour un projet de loisir.

Le workflow de release. Dès qu'un tag comme v0.7.4 est poussé, GitHub Actions construit le paquet complet : les installateurs Windows (Setup, Portable, MSI), un build Linux, un build WebGL pour le navigateur et une image Docker pour le serveur – six artefacts à partir d'un seul tag. Le numéro de version vient du tag lui-même ; il n'y a qu'une seule source de vérité.

Le workflow de déploiement. Un deuxième workflow amène les nouvelles versions sur le serveur. Ce qui comptait pour nous, c'était une validation avant la production : le déploiement ne démarre qu'une fois explicitement approuvé. Pas de « oups, c'était la prod » par accident. Le serveur lui-même fixe la version du jeu dans un fichier de configuration – chaque monde qui se réveille démarre alors automatiquement avec la nouvelle version, tandis que les mondes en cours ne sont pas interrompus.

Une leçon qu'il a fallu apprendre : les correctifs du client de jeu n'arrivent chez les joueurs qu'avec une vraie release. Notre client se met à jour via Velopack – quiconque a installé le jeu ne reçoit des mises à jour que lorsque nous publions une nouvelle version. Un correctif fusionné sur la branche main n'aide personne tant qu'aucun tag ne suit. Ça paraît évident, mais plus d'une fois, nous nous sommes demandé pourquoi un bug « corrigé » était toujours là.

Et le navigateur ? Le build WebGL est déposé sur le serveur sous forme de ZIP, puis activé en échangeant les répertoires – l'ancien répertoire reste là en solution de secours. Un petit version.txt indique ce qui est en ligne en ce moment.

Toute cette machinerie nous a coûté quelques week-ends – et elle se rentabilise à nouveau à chaque release.