Cómo sincronizar configuraciones entre ambientes en tu servidor de MU Online

Un problema común en servidores de MU Online administrados por más de una persona es la divergencia silenciosa de configuración entre ambientes: el administrador prueba un cambio en staging, funciona, pero olvida aplicar el mismo cambio en producción —o peor, aplica una versión ligeramente diferente, generando un bug que solo aparece frente a los jugadores. Sincronizar configuraciones entre ambientes de forma sistemática, con un proceso claro de "qué es igual en todas partes" versus "qué es específico de cada ambiente", elimina esta clase completa de error. Este tutorial muestra cómo estructurar ese proceso, desde los archivos de plantilla hasta el flujo de promoción de cambios.

El problema de la configuración divergente

Los servidores de MU suelen tener decenas de archivos de configuración dispersos: GameServerInfo.dat, ConnectServerInfo.dat, archivos .ini de balanceo (tasa de experiencia, drop, PvP), configuraciones de eventos, y las cadenas de conexión de la base de datos. Cuando cada ambiente (desarrollo, staging, producción) tiene esos archivos editados manualmente y sin control, es prácticamente seguro que divergen de formas no documentadas —y el día en que esto se descubre suele ser el día en que algo ya se rompió en producción.

Separando lo común de lo específico por ambiente

El primer paso conceptual es clasificar cada configuración en dos categorías:

Mezclar ambas categorías en el mismo archivo es lo que causa la mayoría de los problemas —un archivo de configuración de evento no debería contener, en la misma estructura, la contraseña de la base de datos de producción.

Estructura de plantillas de configuración

En vez de mantener un archivo de configuración completo por ambiente, mantén una plantilla versionada con placeholders, y genera el archivo final en el momento del despliegue sustituyendo los placeholders por los valores del ambiente:

; plantilla: GameServerInfo.template.ini
[Database]
Server={{DB_HOST}}
Database=MuOnline
User={{DB_USER}}
Password={{DB_PASSWORD}}

[Rates]
ExperienceRate=1.0
DropRate=0.7
ZenRate=1.0

[Server]
ServerName={{SERVER_NAME}}
MaxConnections={{MAX_CONNECTIONS}}

Las tasas de experiencia y drop son iguales en staging y producción (para que la prueba sea representativa); el host de la base de datos y el nombre del servidor cambian por ambiente.

Generando el archivo final por ambiente

Un script simple de sustitución de placeholders, usando variables de ambiente específicas de cada lugar:

#!/bin/bash
set -euo pipefail
ENV_FILE=".env.$1"   # ej: .env.staging o .env.produccion
source "$ENV_FILE"

envsubst < config/GameServerInfo.template.ini > /opt/mu-server/config/GameServerInfo.ini

echo "[sync] Configuración generada para el ambiente: $1"

Cada ambiente tiene su propio archivo .env (nunca commiteado en Git —solo un .env.example con placeholders va al repositorio), garantizando que los valores sensibles queden fuera del control de versión pero la estructura permanezca idéntica.

# .env.staging (no versionado)
DB_HOST=10.1.2.10
DB_USER=gameserver_svc_staging
DB_PASSWORD=SenhaStaging123
SERVER_NAME=MU-Staging
MAX_CONNECTIONS=50

# .env.produccion (no versionado)
DB_HOST=10.0.3.10
DB_USER=gameserver_svc
DB_PASSWORD=SenhaProducaoForte!2026
SERVER_NAME=MU-Produccion
MAX_CONNECTIONS=1000

Flujo de promoción de cambios entre ambientes

Todo cambio de configuración común (tasas, eventos, reglas) debe seguir un flujo de promoción, nunca editarse directamente en producción:

1. El cambio se hace en la plantilla versionada, en una rama de desarrollo.
2. La plantilla se aplica primero en staging, generando el archivo final con las variables de staging.
3. El equipo prueba el comportamiento en staging (evento, tasa nueva, ítem nuevo).
4. Si se aprueba, el cambio se fusiona (merge) en la rama principal.
5. El pipeline de despliegue aplica la misma plantilla en producción, con las variables de producción.

Este flujo garantiza que producción nunca recibe una configuración que no haya pasado antes por staging —eliminando la divergencia silenciosa.

Comparando ambientes automáticamente

Para detectar divergencias que ya existen (archivos editados manualmente en el pasado, fuera del proceso), un script de comparación estructural ayuda a identificar lo que diverge más allá de lo esperado:

#!/bin/bash
# Compara las claves presentes en cada ambiente, ignorando valores esperados como diferentes
diff <(grep -oP '^\w+(?==)' /opt/mu-server-staging/config/GameServerInfo.ini | sort) \
     <(grep -oP '^\w+(?==)' /opt/mu-server-producao/config/GameServerInfo.ini | sort)

Si la salida del diff no está vacía, significa que una clave existe en un ambiente y no en el otro —una señal clara de configuración que salió de sincronía.

Tabla de configuraciones típicas y su categoría

Sincronizando el esquema de base de datos entre ambientes

Además de los archivos de configuración, el esquema de la base de datos (tablas, columnas, stored procedures) también necesita estar sincronizado. Usa el mismo conjunto de migraciones versionadas (ver el tutorial de despliegue continuo) aplicado en ambos ambientes, en el mismo orden, nunca alterando el esquema manualmente de forma directa en producción después de haberlo probado en staging.

Manejando datos sensibles al sincronizar staging con producción

Cuando staging necesita una copia de datos de producción para pruebas más realistas (no solo configuración, sino datos), nunca copies el dump en bruto. Anonimízalo antes:

-- Ejecutar solo en la base de staging, después de restaurar una copia
UPDATE Account SET Password = 'hash_generico_de_teste', Email = 'teste+' + CAST(AccountID AS VARCHAR) + '@staging.local';
UPDATE MEMB_STAT SET bloc1='0',bloc2='0',bloc3='0',bloc4='0' WHERE 1=1; -- ejemplo de vaciar campos sensibles de pago, si existen

Documenta este script de anonimización como parte del proceso de sincronización de datos, no como un paso manual "recordado de memoria".

Herramientas que ayudan a formalizar este proceso

Para equipos más grandes, las herramientas de gestión de configuración (Ansible, Terraform para infraestructura, o incluso un simple sistema de plantillas con Jinja2/envsubst como se mostró arriba) hacen este proceso auditable y repetible. Lo importante no es qué herramienta usar, sino el principio: ninguna configuración debe existir solo en la cabeza o en la terminal de un administrador —todo debe estar versionado, con un proceso claro de cómo pasa de un ambiente a otro.

Errores comunes y soluciones

Lista de verificación de sincronización de ambientes

• Configuraciones clasificadas entre "común" y "específica de ambiente".
• Plantillas versionadas en Git, sin secretos embebidos.
• Archivos .env por ambiente, fuera del control de versión.
• Flujo de promoción (staging antes de producción) documentado y seguido.
• Script de comparación estructural ejecutado periódicamente para detectar divergencias.
• Esquema de base de datos sincronizado vía migraciones versionadas, no edición manual.
• Proceso de anonimización definido para datos copiados de producción a staging.

Con las configuraciones sincronizadas de forma confiable entre ambientes, el siguiente paso es conectar este proceso al pipeline de despliegue automatizado —consulta el tutorial de script de despliegue continuo para servidor de MU Online para cerrar el ciclo entre configuración, build y publicación en producción.

Preguntas frecuentes