Cómo crear un changelog automático a partir del Git para tu servidor de MU Online

Todo servidor de MU Online que evoluciona con frecuencia —corrigiendo bugs, balanceando ítems, agregando eventos— enfrenta el mismo problema de comunicación: ¿cómo avisar a la comunidad de lo que cambió, sin depender de que alguien recuerde escribir manualmente un post de "novedades" en cada actualización? La respuesta es automatizar el changelog a partir del propio historial de Git, usando un estándar de mensajes de commit que la computadora pueda interpretar. Este tutorial muestra cómo adoptar Conventional Commits, generar changelogs automáticamente con semantic-release y publicar esas notas de versión en el sitio y en Discord sin trabajo manual repetido.

Por qué generar el changelog a partir de Git

Escribir el changelog manualmente tiene dos problemas recurrentes: o se olvida (nadie se acuerda de actualizarlo) o queda genérico ("correcciones varias"). Cuando el changelog nace del historial de commits, cada cambio ya documentado en el código se convierte automáticamente en una línea del changelog, categorizada por tipo (funcionalidad nueva, corrección, cambio que rompe compatibilidad). El equipo solo necesita escribir un buen mensaje de commit una vez; el resto es automático.

El estándar Conventional Commits

Todo mensaje de commit sigue un formato fijo que describe el tipo de cambio y el alcance afectado:

<tipo>(<alcance>): <descripción corta>

<cuerpo opcional con más detalles>

<pie opcional, ej: BREAKING CHANGE>

Requisitos previos

• Repositorio Git del servidor (scripts de configuración, base de datos, panel web) ya versionado.
• Node.js 18+ instalado en la máquina de build/CI.
• Acceso de escritura al repositorio y permisos de release (tags).
• Un pipeline de CI configurado (GitHub Actions, GitLab CI o Gitea Actions).

Paso 1 — Estandarizar los mensajes de commit

Instala commitlint para validar los mensajes antes de aceptar el commit:

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

Crea el archivo commitlint.config.js:

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

A partir de aquí, un commit como corregido bug del drop será rechazado; el equipo debe escribir fix(drop): corrige tasa de drop de jewel en Devil Square.

Paso 2 — Instalar y configurar semantic-release

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

Archivo .releaserc.json:

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

El commit-analyzer decide si la próxima versión es patch, minor o major según los tipos de commit desde el último release. El release-notes-generator arma el texto; @semantic-release/changelog lo escribe en CHANGELOG.md; @semantic-release/git hace commit del changelog actualizado de vuelta al repositorio.

Paso 3 — Configurar el pipeline de CI

Ejemplo de workflow en 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 }}

Cada vez que un merge cae en la rama main, el pipeline analiza los commits nuevos, decide la versión, genera el changelog y crea el tag y el release automáticamente.

Paso 4 — Publicar el changelog en el sitio del servidor

Agrega un paso extra al pipeline que envíe el contenido generado al repositorio de contenido del sitio (o dispare un webhook de rebuild), transformando cada release en un post en la página de "Novedades" del portal. Esto cierra el ciclo: el desarrollador solo escribe un buen mensaje de commit, y el jugador ve la novedad publicada sin intervención manual.

Paso 5 — Notificar automáticamente en Discord

Un paso adicional en el workflow puede enviar el changelog generado a un webhook de Discord, formateado como embed, apenas se publique el release:

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

Categorización de cambios relevantes para los jugadores

No todo cambio técnico interesa al jugador final. Separa el changelog en dos públicos:

Usa alcances de commit (feat(evento), fix(drop), chore(deps)) para automatizar esta separación con un filtro simple en el script de publicación.

Versionamiento semántico aplicado al servidor

Adopta versiones en el formato MAJOR.MINOR.PATCH. Un fix sube el PATCH (ej: 2.4.1 → 2.4.2), un feat sube el MINOR (2.4.2 → 2.5.0), y un BREAKING CHANGE sube el MAJOR (2.5.0 → 3.0.0) —por ejemplo, una migración de base de datos que exige reset de personajes o un cambio incompatible en la API del panel web.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Conventional Commits adoptado y validado por commitlint.
• semantic-release configurado con los plugins de changelog y git.
• Pipeline de CI creando tags y releases automáticamente.
• Changelog público (jugadores) separado del changelog técnico interno.
• Publicación automática en el sitio probada de punta a punta.
• Notificación en Discord configurada y validada.
• Versionamiento semántico documentado para el equipo.

Con el changelog automatizado, cada actualización de tu servidor pasa a ser rastreable y comunicada sin esfuerzo manual —el siguiente paso natural es conectar este pipeline al proceso de despliegue del servidor de MU Online, haciendo que toda release publicada también dispare la actualización del entorno de producción.

Preguntas frecuentes