Como montar um pipeline de CI para mudanças no servidor de MU Online

Mudar arquivos de configuração de um servidor de MU Online em produção sem processo — editando direto no servidor via RDP, sem backup, sem teste prévio — é a receita mais comum para incidentes: GameServer que não sobe, evento que não dispara, item duplicado por uma condição mal configurada. Um pipeline de CI (integração contínua) traz para a operação de servidores privados a mesma disciplina usada em desenvolvimento de software: toda mudança passa por controle de versão, validação automatizada e um ambiente de teste antes de chegar à produção. Este tutorial mostra como estruturar esse pipeline especificamente para as particularidades de um servidor de MU (arquivos de configuração, scripts SQL, binários de cliente).

Por que tratar configuração de servidor como código

Os arquivos que definem o comportamento do seu servidor — Item.txt, MonsterSetBase.txt, configurações de drop, scripts de evento, procedures SQL — são, na prática, código: eles determinam comportamento, têm dependências entre si e podem quebrar o sistema se editados incorretamente. Tratá-los como código significa aplicar as mesmas práticas: versionamento, revisão antes de aplicar, ambiente de teste isolado e histórico auditável de quem mudou o quê e quando.

Estrutura de repositório recomendada

Organize um repositório Git (privado) espelhando a estrutura de pastas do servidor, separando claramente o que é configuração versionável do que é gerado/binário grande demais para versionar diretamente:

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

Arquivos binários grandes (modelos BMD de itens/asas customizadas, texturas) vão em um repositório separado ou usando Git LFS, para não inchar o histórico do repositório principal de configuração.

Ambientes: local, staging e produção

Um pipeline de CI só funciona com pelo menos dois ambientes além da máquina de desenvolvimento: staging (réplica fiel da produção, mas isolada, sem jogadores reais) e produção (o servidor que os jogadores acessam). Toda mudança percorre o mesmo caminho: editar localmente → commit → deploy automático em staging → validação → aprovação manual → deploy em produção.

Definindo o pipeline no GitHub Actions

Um workflow básico de CI para este cenário cobre três estágios: validação de sintaxe, deploy em staging e, mediante aprovação, deploy em produção.

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 sintaxe dos arquivos de configuração
        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 em staging
        run: powershell -File scripts/deploy_staging.ps1
      - name: Smoke test (login, criar personagem)
        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 em produção (com aprovação manual)
        run: powershell -File scripts/deploy_production.ps1

O job deploy-producao usa um environment protegido no GitHub, exigindo aprovação manual de um responsável antes de executar — isso evita que qualquer merge dispare deploy direto em produção sem revisão humana final.

Runners self-hosted: por que são necessários aqui

Diferente de um pipeline de aplicação web comum, o deploy de um servidor de MU precisa rodar em uma máquina Windows com acesso direto ao MuServer e ao SQL Server — normalmente a própria máquina do servidor ou uma intermediária na mesma rede. Por isso, os estágios de deploy usam runners self-hosted (agentes do GitHub Actions instalados na sua própria infraestrutura), enquanto a validação de sintaxe, que não depende do ambiente real, pode rodar em runners hospedados (windows-latest).

Testes automatizados possíveis nesse contexto

Smoke tests podem ser scriptados com um cliente de teste automatizado ou, no mínimo, um checklist manual rápido executado por um GM antes da aprovação de produção.

Gerenciando migrações de banco de dados com versionamento

Scripts SQL que alteram schema (novas colunas, tabelas de log, procedures) devem seguir numeração sequencial e ser idempotentes sempre que possível — ou seja, seguros para rodar mais de uma vez sem duplicar efeito:

-- 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

Mantenha uma tabela de controle (SchemaVersion) registrando quais migrações já rodaram em cada ambiente, evitando reaplicar scripts já executados.

Rollback: planejando a saída antes da entrada

Todo deploy precisa de um plano de rollback documentado antes de ser executado, não improvisado depois de um incidente. Para arquivos de configuração, isso significa manter a versão anterior sempre disponível (o próprio Git já cobre isso via git revert); para mudanças de schema SQL, cada migração deveria ter um script de reversão correspondente (002_add_event_log_table_rollback.sql) testado em staging antes de ir para produção.

Aprovação e trilha de auditoria

Use pull requests como o mecanismo formal de revisão: nenhuma mudança de configuração vai para a branch principal sem pelo menos uma aprovação de outro membro da equipe (ou, em times menores, uma segunda checagem própria em outro dia, para reduzir viés de "parece certo porque acabei de escrever"). O histórico do Git, combinado ao log de aprovações do GitHub, vira a trilha de auditoria: quem mudou o quê, quando, e quem aprovou.

Erros comuns e soluções

Checklist de pipeline de CI

• Repositório Git criado com estrutura espelhando as pastas do servidor.
• Ambiente de staging isolado configurado como réplica de produção.
• Workflow de CI com validação de sintaxe em todo commit.
• Smoke tests automatizados ou checklist manual pós-deploy em staging.
• Aprovação manual obrigatória antes de deploy em produção.
• Scripts de migração SQL numerados, idempotentes e com rollback testado.
• Branch principal protegida, exigindo pull request e revisão.
• Trilha de auditoria (quem mudou o quê, quando) acessível pelo histórico do Git.

Com o pipeline funcionando, cada mudança de configuração, sistema custom ou script SQL passa a ser rastreável e reversível — uma base sólida para evoluir com segurança os sistemas mais avançados do servidor, como os descritos no tutorial de criação de servidor de MU Online.

Perguntas frequentes