Cómo automatizar el deploy de archivos del servidor de MU Online

Automatizar el deploy de un servidor de MU Online es la diferencia entre un mantenimiento tranquilo de cinco minutos y una madrugada entera copiando archivos a mano, rogando por no haber olvidado nada. En un servidor privado típico conviven varios procesos interdependientes —ConnectServer, GameServer, DataServer, el servicio de eventos y el sitio web— y todos leen los mismos archivos de configuración y binarios. Cambiar un .exe o un .dat con el proceso en ejecución simplemente no funciona en Windows, porque el sistema mantiene el archivo bloqueado. Además, una copia hecha a mano está sujeta a error humano: un archivo olvidado, una carpeta cambiada, un permiso perdido. Este tutorial muestra cómo transformar todo ese ritual en un pipeline predecible: un script que hace backup del estado actual, tumba los servicios en el orden correcto, sincroniza los archivos nuevos, sube todo de vuelta y, si algo sale mal, permite volver al estado anterior con un solo comando. Vamos a usar PowerShell como ejemplo por ser nativo de Windows, donde corre la mayoría de los servidores de MU, pero la lógica se aplica a cualquier herramienta. Recuerda: las rutas, los nombres de servicio y la estructura de carpetas varían por emulador/versión, así que trata los ejemplos como un esqueleto a adaptar, no como una verdad absoluta.

Requisitos previos

Antes de escribir la primera línea de automatización, ten claro el mapa de tu servidor. Si aún estás montando el entorno desde cero, vale la pena revisar primero la guía de cómo crear un servidor de MU Online, porque la automatización solo tiene sentido sobre una base que ya funciona manualmente.

Vas a necesitar:

• Acceso administrativo a la máquina del servidor (el deploy toca servicios y carpetas protegidas).
• PowerShell 5.1 o superior, ya incluido en Windows Server y en Windows 10/11.
• Estructura de carpetas conocida: dónde están los binarios (ConnectServer, GameServer, DataServer), los archivos de configuración y los datos del juego.
• Una carpeta de origen (staging) con los archivos ya validados que se van a publicar.
• Espacio en disco suficiente para guardar al menos los últimos 3 a 5 backups completos de la carpeta del servidor.
• Permiso para escribir en los servicios vía Stop-Service/Start-Service o, si los procesos corren como aplicaciones comunes, vía Stop-Process/Start-Process.

Un detalle importante: no todo emulador registra los componentes como servicios de Windows. Muchos corren como ejecutables simples abiertos en una sesión. Eso cambia la forma de detener y subir cada pieza, y el script debe reflejar tu realidad. Varía por emulador/versión.

Entendiendo el orden de parada y arranque

El orden importa más de lo que parece. Los componentes de un servidor de MU tienen dependencias claras:

La regla práctica: tumba de arriba hacia abajo (de lo que los jugadores tocan primero) y sube de abajo hacia arriba (desde los cimientos). El ConnectServer es la puerta de entrada, así que es el primero en caer para impedir nuevos logins durante el cambio. El DataServer es la base que habla con SQL, así que es el primero en volver. Invertir esto genera GameServers que suben sin poder registrarse y quedan en un bucle de error.

Paso 1 — Definir variables y estructura del script

Comienza aislando en variables al inicio del script todo lo que cambia entre entornos. Eso evita rutas "clavadas" esparcidas por el código.

# deploy.ps1 - ejemplo (adapta rutas y nombres a tu emulador/version)
$ServidorPath = "D:\MuServer"           # destino en produccion
$StagingPath  = "D:\Deploy\staging"     # archivos nuevos validados
$BackupRoot   = "D:\Deploy\backups"
$Timestamp    = Get-Date -Format "yyyyMMdd_HHmmss"
$BackupPath   = Join-Path $BackupRoot $Timestamp
$LogFile      = "D:\Deploy\logs\deploy_$Timestamp.log"

# Procesos/servicios en el ORDEN DE PARADA
$ProcessosParar = @("ConnectServer","GameServer","DataServer")
# En el arranque usaremos el orden inverso

Adopta siempre un Timestamp en la creación del backup. Es lo que hace posible y rastreable el rollback: cada deploy deja una fotografía fechada del estado anterior.

Paso 2 — Registrar todo en un log

Un deploy sin log es un deploy que no puedes depurar a las tres de la mañana. Crea una función simple de log que escriba en pantalla y en archivo al mismo tiempo.

function Write-Log {
    param([string]$Msg, [string]$Nivel = "INFO")
    $linha = "{0} [{1}] {2}" -f (Get-Date -Format "HH:mm:ss"), $Nivel, $Msg
    Write-Host $linha
    Add-Content -Path $LogFile -Value $linha
}

Llama a Write-Log en cada etapa relevante: inicio, backup concluido, cada servicio parado, copia finalizada, cada servicio subido. Cuando algo falle, el log dirá exactamente en qué punto se atascó el pipeline.

Paso 3 — Backup antes que nada

Esta es la etapa innegociable. Nunca sobrescribas un archivo de producción sin antes copiar el estado actual a un lugar seguro. El backup pre-deploy es tu paracaídas.

Write-Log "Iniciando backup de $ServidorPath"
New-Item -ItemType Directory -Path $BackupPath -Force | Out-Null

robocopy $ServidorPath $BackupPath /E /R:2 /W:3 /NFL /NDL /NP | Out-Null

if ($LASTEXITCODE -ge 8) {
    Write-Log "FALLO en el backup. Abortando deploy." "ERRO"
    exit 1
}
Write-Log "Backup concluido en $BackupPath"

Una observación sobre el robocopy: sus códigos de salida no siguen la convención común. Los valores de 0 a 7 indican éxito (con o sin archivos copiados); 8 o más indican un error real. Por eso la verificación es -ge 8 y no -ne 0. Ignorar ese detalle hace que el script aborte sin motivo en cada ejecución.

Nota que este backup cubre solo los archivos del servidor. La base de datos tiene su propio ciclo de vida y no debe ser tocada por el deploy de archivos: necesita una rutina separada de backup en SQL Server. Mezclar las dos cosas es una fuente clásica de dolor de cabeza.

Paso 4 — Detener los servicios en el orden correcto

Con el backup en su lugar, tumba los procesos. El tratamiento depende de cómo tu emulador ejecuta cada pieza.

foreach ($proc in $ProcessosParar) {
    Write-Log "Parando $proc"
    $p = Get-Process -Name $proc -ErrorAction SilentlyContinue
    if ($p) {
        $p | Stop-Process -Force
        Start-Sleep -Seconds 2
        Write-Log "$proc parado"
    } else {
        Write-Log "$proc no estaba en ejecucion" "AVISO"
    }
}

Si, en tu caso, los componentes son servicios registrados de Windows, cámbialo por Stop-Service -Name $proc -Force. El Start-Sleep da tiempo para que el sistema libere los locks de archivo antes de intentar la copia. Sin esa pausa, la etapa siguiente puede fallar con "archivo en uso". Varía por emulador/versión si los componentes son servicios o procesos sueltos.

Paso 5 — Sincronizar los archivos nuevos

Ahora que nada está sujetando los archivos, copia el staging a producción. Usa robocopy de nuevo, con cuidado de no borrar datos que no deben ser tocados.

Write-Log "Copiando archivos de $StagingPath a $ServidorPath"
robocopy $StagingPath $ServidorPath /E /R:2 /W:3 /XD "Backup" /NFL /NDL /NP | Out-Null

if ($LASTEXITCODE -ge 8) {
    Write-Log "FALLO en la copia. Iniciando rollback." "ERRO"
    # llamada de rollback aqui (Paso 7)
    exit 1
}
Write-Log "Archivos sincronizados con exito"

Fíjate en el /XD (exclude directory): úsalo para carpetas que el deploy jamás debe alterar, como logs, dumps o datos persistentes. Si usas la flag /MIR (espejo), ten mucho cuidado: borra en el destino todo lo que no existe en el origen, lo que puede destruir configuraciones locales. Para un deploy incremental, prefiere /E (copia subcarpetas, incluso vacías) sin espejado.

Paso 6 — Subir los servicios en el orden inverso

Cimientos primero. Sube en el orden contrario al de parada.

$ProcessosSubir = @(
    @{ Nome="DataServer";    Exe="D:\MuServer\DataServer\DataServer.exe" }
    @{ Nome="GameServer";    Exe="D:\MuServer\GameServer\GameServer.exe" }
    @{ Nome="ConnectServer"; Exe="D:\MuServer\ConnectServer\ConnectServer.exe" }
)

foreach ($s in $ProcessosSubir) {
    Write-Log "Subiendo $($s.Nome)"
    Start-Process -FilePath $s.Exe
    Start-Sleep -Seconds 5
    $ok = Get-Process -Name $s.Nome -ErrorAction SilentlyContinue
    if ($ok) { Write-Log "$($s.Nome) online" }
    else     { Write-Log "$($s.Nome) NO subio" "ERRO" }
}

El Start-Sleep de 5 segundos entre cada pieza da tiempo para que el DataServer se registre antes de que el GameServer intente conectar, y para que el GameServer esté listo antes de que el ConnectServer acepte jugadores. Ajusta el tiempo a la velocidad de tu máquina. Varía por emulador/versión.

Paso 7 — Rollback automático

El rollback es simplemente el inverso del deploy: detener los servicios, restaurar la carpeta de backup y subir de nuevo. Encapsúlalo en una función reutilizable.

function Invoke-Rollback {
    param([string]$BackupDir)
    Write-Log "ROLLBACK a partir de $BackupDir" "AVISO"
    foreach ($proc in $ProcessosParar) {
        Get-Process -Name $proc -ErrorAction SilentlyContinue | Stop-Process -Force
    }
    Start-Sleep -Seconds 3
    robocopy $BackupDir $ServidorPath /E /R:2 /W:3 /NFL /NDL /NP | Out-Null
    Write-Log "Archivos restaurados. Sube los servicios manualmente y valida."
}

Llama a esa función siempre que una etapa crítica falle, pasando el $BackupPath de aquel deploy. El punto clave es que el backup se creó antes de cualquier alteración, así que la restauración devuelve el servidor exactamente al estado que funcionaba. Guarda los últimos backups y limpia los antiguos periódicamente para no llenar el disco.

# Retencion: mantener solo los 5 backups mas recientes
Get-ChildItem $BackupRoot -Directory |
    Sort-Object Name -Descending |
    Select-Object -Skip 5 |
    Remove-Item -Recurse -Force

Paso 8 — Validación post-deploy

Subir los procesos no garantiza que el servidor esté sano. Haz verificaciones objetivas:

1. Confirma que cada proceso aparece en la lista (Get-Process).
2. Prueba si los puertos del ConnectServer y del GameServer están escuchando con Test-NetConnection -ComputerName 127.0.0.1 -Port <puerto>.
3. Haz un login de prueba con una cuenta reservada para eso.
4. Verifica los logs de los propios componentes en busca de errores de registro o de conexión con la base de datos.

Solo declara el mantenimiento terminado después de que un login real funcione. Un proceso "de pie" pero que no acepta conexiones es peor que un proceso caído, porque da una falsa sensación de éxito.

Paso 9 — Programación con el Programador de tareas

Para deploys recurrentes o de madrugada, registra el script en el Programador de tareas de Windows. Haz esto solo con scripts ya probados exhaustivamente.

$acao = New-ScheduledTaskAction -Execute "powershell.exe" `
    -Argument "-NoProfile -ExecutionPolicy Bypass -File D:\Deploy\deploy.ps1"
$gatilho = New-ScheduledTaskTrigger -Daily -At 04:00
Register-ScheduledTask -TaskName "MU Deploy" -Action $acao -Trigger $gatilho `
    -RunLevel Highest -Description "Deploy automatico del servidor de MU"

Aun programado, mantén un responsable de guardia en las primeras ejecuciones y configura el envío de los logs por correo o webhook. La automatización no elimina la necesidad de supervisión: solo reduce el esfuerzo repetitivo.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Estructura de carpetas y nombres de servicio mapeados y correctos en el script
• La carpeta de staging contiene solo archivos ya validados en el entorno de prueba
• Función de log grabando en un archivo fechado
• Backup pre-deploy probado y con verificación -ge 8
• Política de retención de backups configurada (últimos 3–5)
• Orden de parada: ConnectServer → GameServer → DataServer
• Orden de arranque: DataServer → GameServer → ConnectServer
• Flags de copia revisadas (sin /MIR accidental; /XD en las carpetas protegidas)
• Función de rollback probada restaurando un backup real
• La validación post-deploy incluye un login de prueba con una cuenta reservada
• Backup de la base de datos tratado por una rutina separada
• Ventana de mantenimiento anunciada a los jugadores
• Responsable de guardia definido para acompañar los logs

Con este pipeline en su lugar, el deploy deja de ser una fuente de ansiedad y pasa a ser una operación rutinaria y reversible. La mayor ganancia no es el ahorro de tiempo, sino la confianza: sabes que, si algo sale mal, el backup fechado y la función de rollback devuelven el servidor al aire en minutos. Comienza simple, córrelo manualmente algunas veces, y solo entonces prográmalo. Adapta cada ruta y nombre de servicio a la realidad de tu emulador, porque esos detalles siempre varían por emulador/versión.

Preguntas frecuentes