Del tag de Git al servidor en vivo: nuestra cadena de publicación

Hoy, publicar una versión de Blocks Beyond The Stars consiste en un único comando: hacer push de un tag de Git. Todo lo demás lo hace la máquina. En este artículo te enseño nuestra cadena de CI/CD, y por qué el esfuerzo vale la pena incluso para un proyecto de afición.

El flujo de publicación. En cuanto se sube un tag como v0.7.4, GitHub Actions construye el paquete completo: instaladores para Windows (setup, portable, MSI), una compilación para Linux, una compilación WebGL para el navegador y una imagen Docker para el servidor: seis artefactos a partir de un solo tag. El número de versión sale del propio tag; solo hay una fuente de verdad.

El flujo de despliegue. Un segundo flujo de trabajo lleva las versiones nuevas al servidor. Para nosotros era importante tener una puerta de producción: el despliegue solo arranca cuando alguien lo ha aprobado explícitamente. Nada de “uy, eso era producción” por accidente. El propio servidor fija la versión del juego en un archivo de configuración: cada mundo que despierta arranca automáticamente con la nueva versión, mientras que los mundos en marcha no se interrumpen.

Una lección que tuvimos que aprender: las correcciones en el cliente del juego solo llegan a los jugadores con una versión publicada de verdad. Nuestro cliente se actualiza solo mediante Velopack: quien tiene el juego instalado solo recibe actualizaciones cuando publicamos una versión nueva. Una corrección fusionada en la rama main no ayuda a nadie mientras no le siga un tag. Parece obvio, pero más de una vez nos preguntamos por qué seguía ahí un bug “corregido”.

¿Y el navegador? La compilación WebGL se deja en el servidor como ZIP y se activa intercambiando directorios: el directorio antiguo se queda como respaldo. Un pequeño version.txt revela qué está en vivo en cada momento.

Montar todo el aparato nos costó unos cuantos fines de semana, y se amortiza de nuevo con cada versión.