Dal tag Git al server live: la nostra pipeline di rilascio

Oggi una release di Blocks Beyond The Stars consiste in un solo comando: fare il push di un tag git. Tutto il resto lo fa la macchina. In questo articolo mostro la nostra pipeline CI/CD e perché la fatica vale la pena anche per un progetto per hobby.

Il workflow di rilascio. Appena viene inviato un tag come v0.7.4, GitHub Actions costruisce il pacchetto completo: installer per Windows (setup, portable, MSI), una build per Linux, una build WebGL per il browser e un'immagine Docker per il server: sei artefatti da un solo tag. Il numero di versione viene dal tag stesso; c'è una sola fonte di verità.

Il workflow di deploy. Un secondo workflow porta le nuove versioni sul server. Per noi contava un gate di produzione: il deploy parte solo dopo essere stato approvato esplicitamente. Niente «ops, era la produzione». Il server stesso fissa la versione del gioco in un file di configurazione: ogni mondo che si risveglia parte poi automaticamente con la nuova versione, mentre i mondi in esecuzione non vengono interrotti.

Una lezione che abbiamo dovuto imparare: le correzioni nel client di gioco arrivano ai giocatori solo con una release vera. Il nostro client si aggiorna da solo tramite Velopack: chi ha installato il gioco riceve aggiornamenti solo quando pubblichiamo una nuova versione. Una correzione unita nel ramo principale non aiuta nessuno finché non segue un tag. Sembra ovvio, ma più di una volta ci siamo chiesti perché un bug «risolto» fosse ancora lì.

E il browser? La build WebGL viene depositata sul server come ZIP e attivata con uno scambio di cartelle: la vecchia cartella resta come ripiego. Un piccolo version.txt rivela che cosa è attualmente online.

L'intero apparato è costato qualche fine settimana, e si ripaga di nuovo a ogni rilascio.