Da tag do Git ao servidor no ar: nosso pipeline de lançamento

Hoje, um lançamento de Blocks Beyond The Stars consiste em um único comando: enviar uma tag do Git. Tudo o que vem depois é feito pela máquina. Neste artigo vou mostrar nosso pipeline de CI/CD — e por que o esforço compensa até em um projeto de hobby.

O workflow de lançamento. Assim que uma tag como v0.7.4 é enviada, o GitHub Actions monta o pacote completo: instaladores para Windows (setup, portátil, MSI), uma versão para Linux, uma versão WebGL para o navegador e uma imagem Docker para o servidor — seis artefatos a partir de uma tag. O número da versão vem da própria tag; existe uma única fonte da verdade.

O workflow de deploy. Um segundo workflow leva as versões novas para o servidor. O que importava para nós era um portão de produção: o deploy só começa depois de aprovado explicitamente. Nada de "opa, isso era a produção" por acidente. O próprio servidor fixa a versão do jogo em um arquivo de configuração — cada mundo que acorda passa então a iniciar automaticamente com a versão nova, enquanto os mundos em execução não são interrompidos.

Uma lição que tivemos que aprender: correções no cliente do jogo só chegam aos jogadores com um lançamento de verdade. Nosso cliente se atualiza pelo Velopack — quem já instalou o jogo só recebe atualizações quando publicamos uma versão nova. Uma correção de bug mesclada na branch principal não ajuda ninguém enquanto não vier uma tag. Parece óbvio, mas mais de uma vez nos perguntamos por que um bug "corrigido" ainda estava lá.

E o navegador? A versão WebGL é jogada no servidor como um ZIP e ativada por troca de diretório — o diretório antigo fica guardado como reserva. Um pequeno version.txt revela o que está no ar no momento.

Todo esse aparato custou alguns fins de semana — e se paga de novo a cada lançamento.