Como criar um changelog automático a partir do Git para seu servidor de MU Online

Todo servidor de MU Online que evolui com frequência — corrigindo bugs, balanceando itens, adicionando eventos — enfrenta o mesmo problema de comunicação: como avisar a comunidade do que mudou, sem depender de alguém lembrar de escrever manualmente um post de "novidades" a cada atualização? A resposta é automatizar o changelog a partir do próprio histórico do Git, usando um padrão de mensagens de commit que o computador consegue interpretar. Este tutorial mostra como adotar Conventional Commits, gerar changelogs automaticamente com semantic-release, e publicar essas notas de versão no site e no Discord sem trabalho manual repetido.

Por que gerar changelog a partir do Git

Escrever changelog manualmente tem dois problemas recorrentes: ou fica esquecido (ninguém lembra de atualizar) ou fica genérico ("correções diversas"). Quando o changelog nasce do histórico de commits, cada mudança já documentada no código vira automaticamente uma linha de changelog, categorizada por tipo (funcionalidade nova, correção, mudança que quebra compatibilidade). O time só precisa escrever uma boa mensagem de commit uma vez — o resto é automático.

O padrão Conventional Commits

Toda mensagem de commit segue um formato fixo que descreve o tipo de mudança e o escopo afetado:

<tipo>(<escopo>): <descrição curta>

<corpo opcional com mais detalhes>

<rodapé opcional, ex: BREAKING CHANGE>

Pré-requisitos

• Repositório Git do servidor (scripts de configuração, banco, painel web) já versionado.
• Node.js 18+ instalado na máquina de build/CI.
• Acesso de escrita ao repositório e às permissões de release (tags).
• Um pipeline de CI configurado (GitHub Actions, GitLab CI ou Gitea Actions).

Passo 1 — Padronizar as mensagens de commit

Instale o commitlint para validar mensagens antes de aceitar o commit:

npm install --save-dev @commitlint/cli @commitlint/config-conventional husky
npx husky init
echo "npx --no -- commitlint --edit \$1" > .husky/commit-msg

Crie o arquivo commitlint.config.js:

module.exports = { extends: ['@commitlint/config-conventional'] };

A partir daqui, um commit como corrigido bug do drop será rejeitado; o time precisa escrever fix(drop): corrige taxa de drop de jewel em Devil Square.

Passo 2 — Instalar e configurar o semantic-release

npm install --save-dev semantic-release @semantic-release/changelog @semantic-release/git

Arquivo .releaserc.json:

{
  "branches": ["main"],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/changelog",
    "@semantic-release/git"
  ]
}

O commit-analyzer decide se a próxima versão é patch, minor ou major com base nos tipos de commit desde o último release. O release-notes-generator monta o texto; o @semantic-release/changelog grava em CHANGELOG.md; o @semantic-release/git faz commit do changelog atualizado de volta no repositório.

Passo 3 — Configurar o pipeline de CI

Exemplo de workflow em GitHub Actions (.github/workflows/release.yml):

name: Release
on:
  push:
    branches: [main]
jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v4
        with:
          node-version: 18
      - run: npm ci
      - run: npx semantic-release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Toda vez que um merge cair na branch main, o pipeline analisa os commits novos, decide a versão, gera o changelog e cria a tag e o release automaticamente.

Passo 4 — Publicar o changelog no site do servidor

Adicione um passo extra ao pipeline que envia o conteúdo gerado para o repositório de conteúdo do site (ou dispara um webhook de rebuild), transformando cada release em um post na página de "Novidades" do portal. Isso fecha o ciclo: o desenvolvedor só escreve uma boa mensagem de commit, e o jogador vê a novidade publicada sem intervenção manual.

Passo 5 — Notificar automaticamente no Discord

Um passo adicional no workflow pode enviar o changelog gerado para um webhook do Discord, formatado como embed, assim que a release for publicada:

      - name: Notificar Discord
        if: success()
        run: |
          curl -H "Content-Type: application/json" \
            -d "{\"content\": \"📦 Nova versão publicada! Confira o changelog no site.\"}" \
            ${{ secrets.DISCORD_WEBHOOK_URL }}

Categorização de mudanças relevantes para jogadores

Nem toda mudança técnica interessa ao jogador final. Separe o changelog em dois públicos:

Use escopos de commit (feat(evento), fix(drop), chore(deps)) para automatizar essa separação com um filtro simples no script de publicação.

Versionamento semântico aplicado ao servidor

Adote versões no formato MAJOR.MINOR.PATCH. Um fix sobe o PATCH (ex: 2.4.1 → 2.4.2), um feat sobe o MINOR (2.4.2 → 2.5.0), e um BREAKING CHANGE sobe o MAJOR (2.5.0 → 3.0.0) — por exemplo, uma migração de banco que exige reset de personagens ou uma mudança incompatível na API do painel web.

Erros comuns e soluções

Checklist de lançamento

• Conventional Commits adotado e validado por commitlint.
• semantic-release configurado com os plugins de changelog e git.
• Pipeline de CI criando tags e releases automaticamente.
• Changelog público (jogadores) separado do changelog técnico interno.
• Publicação automática no site testada de ponta a ponta.
• Notificação no Discord configurada e validada.
• Versionamento semântico documentado para a equipe.

Com o changelog automatizado, cada atualização do seu servidor passa a ser rastreável e comunicada sem esforço manual — o próximo passo natural é conectar esse pipeline ao processo de deploy do servidor de MU Online, fazendo com que toda release publicada também dispare a atualização do ambiente de produção.

Perguntas frequentes