Como automatizar o deploy de arquivos do servidor de MU Online

Automatizar o deploy de um servidor de MU Online é a diferença entre uma manutenção tranquila de cinco minutos e uma madrugada inteira copiando arquivos na mão, torcendo para não ter esquecido nada. Em um servidor privado típico convivem vários processos interdependentes — ConnectServer, GameServer, DataServer, o serviço de eventos e o site — e todos leem os mesmos arquivos de configuração e binários. Trocar um .exe ou um .dat com o processo em execução simplesmente não funciona no Windows, porque o sistema mantém o arquivo bloqueado. Além disso, uma cópia feita à mão está sujeita a erro humano: um arquivo esquecido, uma pasta trocada, uma permissão perdida. Este tutorial mostra como transformar todo esse ritual em um pipeline previsível: um script que faz backup do estado atual, derruba os serviços na ordem certa, sincroniza os arquivos novos, sobe tudo de volta e, se algo der errado, permite voltar ao estado anterior com um único comando. Vamos usar PowerShell como exemplo por ser nativo do Windows, onde a maioria dos servidores de MU roda, mas a lógica se aplica a qualquer ferramenta. Lembre-se: caminhos, nomes de serviço e estrutura de pastas variam por emulador/versão, então trate os exemplos como esqueleto a adaptar, não como verdade absoluta.

Pré-requisitos

Antes de escrever a primeira linha de automação, tenha claro o mapa do seu servidor. Se você ainda está montando o ambiente do zero, vale revisar primeiro o guia de como criar servidor de MU Online, porque automação só faz sentido sobre uma base que já funciona manualmente.

Você vai precisar de:

• Acesso administrativo à máquina do servidor (o deploy mexe em serviços e em pastas protegidas).
• PowerShell 5.1 ou superior, já incluso no Windows Server e no Windows 10/11.
• Estrutura de pastas conhecida: onde ficam os binários (ConnectServer, GameServer, DataServer), os arquivos de configuração e os dados do jogo.
• Uma pasta de origem (staging) com os arquivos já validados que serão publicados.
• Espaço em disco suficiente para guardar ao menos os últimos 3 a 5 backups completos da pasta do servidor.
• Permissão para escrever nos serviços via Stop-Service/Start-Service ou, se os processos rodam como aplicações comuns, via Stop-Process/Start-Process.

Um detalhe importante: nem todo emulador registra os componentes como serviços do Windows. Muitos rodam como executáveis simples abertos numa sessão. Isso muda a forma de parar e subir cada peça, e o script precisa refletir a sua realidade. Varia por emulador/versão.

Entendendo a ordem de parada e subida

A ordem importa mais do que parece. Os componentes de um servidor de MU têm dependências claras:

A regra prática: derrube de cima para baixo (do que os jogadores tocam primeiro) e suba de baixo para cima (das fundações). O ConnectServer é a porta de entrada, então é o primeiro a cair para impedir novos logins durante a troca. O DataServer é a base que fala com o SQL, então é o primeiro a voltar. Inverter isso gera GameServers que sobem sem conseguir se registrar e ficam em loop de erro.

Passo 1 — Definir variáveis e estrutura do script

Comece isolando tudo que muda entre ambientes em variáveis no topo do script. Isso evita caminhos "chumbados" espalhados pelo código.

# deploy.ps1 - exemplo (adapte caminhos e nomes ao seu emulador/versao)
$ServidorPath = "D:\MuServer"           # destino em producao
$StagingPath  = "D:\Deploy\staging"     # arquivos novos validados
$BackupRoot   = "D:\Deploy\backups"
$Timestamp    = Get-Date -Format "yyyyMMdd_HHmmss"
$BackupPath   = Join-Path $BackupRoot $Timestamp
$LogFile      = "D:\Deploy\logs\deploy_$Timestamp.log"

# Processos/servicos na ORDEM DE PARADA
$ProcessosParar = @("ConnectServer","GameServer","DataServer")
# Na subida usaremos a ordem inversa

Adote sempre um Timestamp na criação do backup. Ele é o que torna o rollback possível e rastreável: cada deploy deixa uma fotografia datada do estado anterior.

Passo 2 — Registrar tudo em log

Um deploy sem log é um deploy que você não consegue depurar às três da manhã. Crie uma função simples de log que escreve na tela e em arquivo ao mesmo tempo.

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
}

Chame Write-Log em cada etapa relevante: início, backup concluído, cada serviço parado, cópia finalizada, cada serviço subido. Quando algo falhar, o log dirá exatamente em que ponto o pipeline travou.

Passo 3 — Backup antes de qualquer coisa

Esta é a etapa inegociável. Nunca sobrescreva um arquivo de produção sem antes copiar o estado atual para um lugar seguro. O backup pré-deploy é o seu paraquedas.

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 "FALHA no backup. Abortando deploy." "ERRO"
    exit 1
}
Write-Log "Backup concluido em $BackupPath"

Uma observação sobre o robocopy: seus códigos de saída não seguem a convenção comum. Valores de 0 a 7 indicam sucesso (com ou sem arquivos copiados); 8 ou mais indicam erro real. Por isso a checagem é -ge 8 e não -ne 0. Ignorar esse detalhe faz o script abortar sem motivo em toda execução.

Note que este backup cobre apenas os arquivos do servidor. O banco de dados tem ciclo de vida próprio e não deve ser tocado pelo deploy de arquivos — ele precisa de uma rotina separada de backup no SQL Server. Misturar as duas coisas é uma fonte clássica de dor de cabeça.

Passo 4 — Parar os serviços na ordem correta

Com o backup no lugar, derrube os processos. O tratamento depende de como seu emulador executa cada peça.

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 nao estava em execucao" "AVISO"
    }
}

Se, no seu caso, os componentes são serviços registrados do Windows, troque por Stop-Service -Name $proc -Force. O Start-Sleep dá tempo para o sistema liberar os locks de arquivo antes de tentarmos a cópia. Sem essa pausa, a etapa seguinte pode falhar com "arquivo em uso". Varia por emulador/versão se os componentes são serviços ou processos soltos.

Passo 5 — Sincronizar os arquivos novos

Agora que nada está segurando os arquivos, copie o staging para produção. Use robocopy novamente, com cuidado para não apagar dados que não devem ser tocados.

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

if ($LASTEXITCODE -ge 8) {
    Write-Log "FALHA na copia. Iniciando rollback." "ERRO"
    # chamada de rollback aqui (Passo 7)
    exit 1
}
Write-Log "Arquivos sincronizados com sucesso"

Repare no /XD (exclude directory): use-o para pastas que o deploy jamais deve alterar, como logs, dumps ou dados persistentes. Se você usar a flag /MIR (espelho), tome muito cuidado — ela apaga no destino tudo que não existe na origem, o que pode destruir configurações locais. Para deploy incremental, prefira /E (copia subpastas, inclusive vazias) sem espelhamento.

Passo 6 — Subir os serviços na ordem inversa

Fundações primeiro. Suba na ordem contrária à 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 "Subindo $($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) NAO subiu" "ERRO" }
}

O Start-Sleep de 5 segundos entre cada peça dá tempo para o DataServer registrar-se antes do GameServer tentar conectar, e para o GameServer estar pronto antes do ConnectServer aceitar jogadores. Ajuste o tempo à velocidade da sua máquina. Varia por emulador/versão.

Passo 7 — Rollback automático

O rollback é simplesmente o inverso do deploy: parar os serviços, restaurar a pasta de backup e subir de novo. Encapsule numa função reutilizável.

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 "Arquivos restaurados. Suba os servicos manualmente e valide."
}

Chame essa função sempre que uma etapa crítica falhar, passando o $BackupPath daquele deploy. O ponto-chave é que o backup foi criado antes de qualquer alteração, então a restauração devolve o servidor exatamente ao estado que funcionava. Guarde os últimos backups e limpe os antigos periodicamente para não lotar o disco.

# Retencao: manter apenas os 5 backups mais recentes
Get-ChildItem $BackupRoot -Directory |
    Sort-Object Name -Descending |
    Select-Object -Skip 5 |
    Remove-Item -Recurse -Force

Passo 8 — Validação pós-deploy

Subir os processos não garante que o servidor está saudável. Faça verificações objetivas:

1. Confirme que cada processo aparece na lista (Get-Process).
2. Teste se as portas do ConnectServer e do GameServer estão escutando com Test-NetConnection -ComputerName 127.0.0.1 -Port <porta>.
3. Faça um login de teste com uma conta reservada para isso.
4. Verifique os logs dos próprios componentes em busca de erros de registro ou de conexão com o banco.

Só declare a manutenção encerrada depois que um login real funcionar. Um processo "de pé" mas que não aceita conexões é pior do que um processo caído, porque dá falsa sensação de sucesso.

Passo 9 — Agendamento com o Agendador de Tarefas

Para deploys recorrentes ou de madrugada, registre o script no Agendador de Tarefas do Windows. Faça isso apenas com scripts já testados exaustivamente.

$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 do servidor de MU"

Mesmo agendado, mantenha um responsável de plantão nas primeiras execuções e configure o envio dos logs por e-mail ou webhook. Automação não elimina a necessidade de supervisão — ela apenas reduz o esforço repetitivo.

Erros comuns e soluções

Checklist de lançamento

• Estrutura de pastas e nomes de serviço mapeados e corretos no script
• Pasta de staging contém apenas arquivos já validados em ambiente de teste
• Função de log gravando em arquivo datado
• Backup pré-deploy testado e com checagem -ge 8
• Política de retenção de backups configurada (últimos 3–5)
• Ordem de parada: ConnectServer → GameServer → DataServer
• Ordem de subida: DataServer → GameServer → ConnectServer
• Flags de cópia revisadas (sem /MIR acidental; /XD nas pastas protegidas)
• Função de rollback testada restaurando um backup real
• Validação pós-deploy inclui login de teste com conta reservada
• Backup do banco de dados tratado por rotina separada
• Janela de manutenção anunciada aos jogadores
• Responsável de plantão definido para acompanhar os logs

Com esse pipeline no lugar, o deploy deixa de ser uma fonte de ansiedade e passa a ser uma operação rotineira e reversível. O maior ganho não é a economia de tempo, e sim a confiança: você sabe que, se algo der errado, o backup datado e a função de rollback devolvem o servidor ao ar em minutos. Comece simples, rode manualmente algumas vezes, e só então agende. Adapte cada caminho e nome de serviço à realidade do seu emulador, porque esses detalhes sempre variam por emulador/versão.

Perguntas frequentes