Cómo montar un pipeline de CI para cambios en el servidor de MU Online

Cambiar archivos de configuración de un servidor de MU Online en producción sin proceso — editando directamente en el servidor vía RDP, sin backup, sin prueba previa — es la receta más común para incidentes: GameServer que no arranca, evento que no se dispara, ítem duplicado por una condición mal configurada. Un pipeline de CI (integración continua) trae a la operación de servidores privados la misma disciplina usada en desarrollo de software: todo cambio pasa por control de versiones, validación automatizada y un entorno de prueba antes de llegar a producción. Este tutorial muestra cómo estructurar ese pipeline específicamente para las particularidades de un servidor de MU (archivos de configuración, scripts SQL, binarios de cliente).

Por qué tratar la configuración del servidor como código

Los archivos que definen el comportamiento de tu servidor — Item.txt, MonsterSetBase.txt, configuraciones de drop, scripts de evento, procedimientos SQL — son, en la práctica, código: determinan comportamiento, tienen dependencias entre sí y pueden romper el sistema si se editan incorrectamente. Tratarlos como código significa aplicar las mismas prácticas: versionado, revisión antes de aplicar, entorno de prueba aislado e historial auditable de quién cambió qué y cuándo.

Estructura de repositorio recomendada

Organiza un repositorio Git (privado) que refleje la estructura de carpetas del servidor, separando claramente lo que es configuración versionable de lo que es generado/binario demasiado grande para versionar directamente:

mu-server-config/
├── GameServer/
│   ├── Data/ItemList.xml
│   ├── Data/MonsterSetBase.txt
│   └── GameServerInfo.dat
├── ConnectServer/
│   └── ConnectServerInfo.dat
├── sql/
│   ├── migrations/
│   │   ├── 001_add_socket_columns.sql
│   │   └── 002_add_event_log_table.sql
│   └── procedures/
├── scripts/
│   ├── deploy_staging.ps1
│   └── deploy_production.ps1
└── .github/workflows/
    └── ci.yml

Los archivos binarios grandes (modelos BMD de ítems/alas personalizadas, texturas) van en un repositorio separado o usando Git LFS, para no inflar el historial del repositorio principal de configuración.

Entornos: local, staging y producción

Un pipeline de CI solo funciona con al menos dos entornos además de la máquina de desarrollo: staging (réplica fiel de producción, pero aislada, sin jugadores reales) y producción (el servidor al que acceden los jugadores). Todo cambio recorre el mismo camino: editar localmente → commit → despliegue automático en staging → validación → aprobación manual → despliegue en producción.

Definiendo el pipeline en GitHub Actions

Un workflow básico de CI para este escenario cubre tres etapas: validación de sintaxis, despliegue en staging y, mediante aprobación, despliegue en producción.

name: CI Servidor MU

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  validar:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4
      - name: Validar sintaxis de los archivos de configuración
        run: powershell -File scripts/validate_config.ps1
      - name: Validar scripts SQL (dry-run)
        run: powershell -File scripts/validate_sql.ps1

  deploy-staging:
    needs: validar
    if: github.ref == 'refs/heads/main'
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - name: Deploy en staging
        run: powershell -File scripts/deploy_staging.ps1
      - name: Smoke test (login, crear personaje)
        run: powershell -File scripts/smoke_test.ps1

  deploy-producao:
    needs: deploy-staging
    if: github.ref == 'refs/heads/main'
    runs-on: self-hosted
    environment:
      name: producao
    steps:
      - name: Deploy en producción (con aprobación manual)
        run: powershell -File scripts/deploy_production.ps1

El job deploy-producao usa un environment protegido en GitHub, exigiendo aprobación manual de un responsable antes de ejecutar — esto evita que cualquier merge dispare un despliegue directo a producción sin revisión humana final.

Runners self-hosted: por qué son necesarios aquí

A diferencia de un pipeline de aplicación web común, el despliegue de un servidor de MU necesita correr en una máquina Windows con acceso directo al MuServer y al SQL Server — normalmente la propia máquina del servidor o una intermedia en la misma red. Por eso, las etapas de despliegue usan runners self-hosted (agentes de GitHub Actions instalados en tu propia infraestructura), mientras que la validación de sintaxis, que no depende del entorno real, puede correr en runners hospedados (windows-latest).

Pruebas automatizadas posibles en este contexto

Los smoke tests pueden scriptarse con un cliente de prueba automatizado o, como mínimo, una lista de verificación manual rápida ejecutada por un GM antes de la aprobación de producción.

Gestionando migraciones de base de datos con versionado

Los scripts SQL que alteran el schema (columnas nuevas, tablas de log, procedimientos) deben seguir numeración secuencial y ser idempotentes siempre que sea posible — es decir, seguros para correr más de una vez sin duplicar el efecto:

-- 002_add_event_log_table.sql
IF NOT EXISTS (SELECT * FROM sys.tables WHERE name = 'EventLog')
BEGIN
    CREATE TABLE EventLog (
        EventLogID INT IDENTITY PRIMARY KEY,
        EventName VARCHAR(100),
        CreateDate DATETIME DEFAULT GETDATE()
    );
END

Mantén una tabla de control (SchemaVersion) registrando qué migraciones ya corrieron en cada entorno, evitando reaplicar scripts ya ejecutados.

Rollback: planificando la salida antes de la entrada

Todo despliegue necesita un plan de rollback documentado antes de ejecutarse, no improvisado después de un incidente. Para archivos de configuración, esto significa mantener la versión anterior siempre disponible (el propio Git ya cubre esto vía git revert); para cambios de schema SQL, cada migración debería tener un script de reversión correspondiente (002_add_event_log_table_rollback.sql) probado en staging antes de pasar a producción.

Aprobación y rastro de auditoría

Usa pull requests como el mecanismo formal de revisión: ningún cambio de configuración va a la rama principal sin al menos una aprobación de otro miembro del equipo (o, en equipos más pequeños, una segunda revisión propia en otro día, para reducir el sesgo de "parece correcto porque acabo de escribirlo"). El historial de Git, combinado con el log de aprobaciones de GitHub, se convierte en el rastro de auditoría: quién cambió qué, cuándo, y quién aprobó.

Errores comunes y soluciones

Lista de verificación de pipeline de CI

• Repositorio Git creado con estructura que refleja las carpetas del servidor.
• Entorno de staging aislado configurado como réplica de producción.
• Workflow de CI con validación de sintaxis en cada commit.
• Smoke tests automatizados o lista de verificación manual post-deploy en staging.
• Aprobación manual obligatoria antes del deploy en producción.
• Scripts de migración SQL numerados, idempotentes y con rollback probado.
• Rama principal protegida, exigiendo pull request y revisión.
• Rastro de auditoría (quién cambió qué, cuándo) accesible desde el historial de Git.

Con el pipeline funcionando, cada cambio de configuración, sistema personalizado o script SQL pasa a ser rastreable y reversible — una base sólida para evolucionar con seguridad los sistemas más avanzados del servidor, como los descritos en el tutorial de creación de servidor de MU Online.

Preguntas frecuentes