Automatiser la génération du CHANGELOG avec les conventional commits

Maintenir un CHANGELOG à jour est souvent relégué au bas de la pile. On se dit “je le ferai avant la release”, et on se retrouve à fouiller dans les logs Git pour reconstituer ce qui a changé.

La solution : standardiser ses messages de commit avec les Conventional Commits, et automatiser la génération du CHANGELOG.

Le format Conventional Commit

Le principe est simple : un format structuré pour les messages de commit :

<type>(<scope>): <description>

[body]
[footer]

Les types principaux :

Exemples concrets

feat(api): ajouter le endpoint de suppression utilisateur

fix(auth): corriger le refresh token expiré

feat(ui): ajouter le dark mode

BREAKING CHANGE: migration vers l'API v2, les routes /api/v1 sont dépréciées

docs(readme): mettre à jour les instructions d'installation

Valider les messages de commit

Pour s’assurer que toute l’équipe respecte le format, on utilise commitlint :

npm install -D @commitlint/cli @commitlint/config-conventional

// commitlint.config.js
module.exports = {
  extends: ["@commitlint/config-conventional"],
  rules: {
    "scope-case": [2, "always", "kebab-case"],
    "subject-case": [2, "always", "lower-case"],
    "subject-max-length": [2, "always", 100],
  },
};

On l’intègre via husky pour valider avant chaque commit :

npm install -D husky
npx husky init

# .husky/commit-msg
npx --no -- commitlint --edit $1

Générer le CHANGELOG automatiquement

Avec standard-version

npm install -D standard-version

// package.json
{
  "scripts": {
    "release": "standard-version",
    "release:minor": "standard-version --release-as minor",
    "release:major": "standard-version --release-as major"
  }
}

npm run release

standard-version va :

1. Analyser les commits depuis la dernière version tagguée
2. Générer ou mettre à jour CHANGELOG.md
3. Créer un commit de release
4. Créer un tag git (ex: v1.2.0)

Avec release-please (Google)

Pour une intégration CI/CD, release-please est plus puissant :

# .github/workflows/release.yml (ou GitLab CI équivalent)
name: Release

on:
  push:
    branches: [main]

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: google-github-actions/release-please-action@v3
        with:
          release-type: node
          package-name: mon-projet

Release-please crée automatiquement une Pull Request de release avec le CHANGELOG généré. On merge la PR, et la release est publiée.

Configuration avancée

On peut personnaliser complètement le comportement :

// .versionrc.json
{
  "types": [
    { "type": "feat", "section": "🚀 Nouvelles fonctionnalités" },
    { "type": "fix", "section": "🐛 Corrections de bugs" },
    { "type": "perf", "section": "⚡ Améliorations de performance" },
    { "type": "docs", "section": "📖 Documentation" },
    { "type": "refactor", "hidden": true },
    { "type": "test", "hidden": true },
    { "type": "chore", "hidden": true }
  ],
  "commitUrlFormat": "https://gitlab.com/monprojet/commits/{{hash}}",
  "compareUrlFormat": "https://gitlab.com/monprojet/compare/{{previousTag}}...{{currentTag}}"
}

Structure du CHANGELOG généré

# Changelog

## [1.5.0] - 2026-06-25

### 🚀 Nouvelles fonctionnalités
- **api**: ajouter le endpoint de suppression utilisateur
- **ui**: ajouter le dark mode
- **auth**: support OAuth2 Google

### 🐛 Corrections de bugs
- **auth**: corriger le refresh token expiré
- **ui**: corriger l'affichage mobile du menu

### ⚡ Améliorations de performance
- **db**: optimiser la requête de recherche (45x plus rapide)

### 📖 Documentation
- **readme**: mettre à jour les instructions d'installation

Intégration dans le pipeline GitLab CI

stages:
  - test
  - release
  - deploy

release:
  stage: release
  only:
    - main
  script:
    - npm ci
    - npm run build
    - npx standard-version
    - git push --follow-tags origin HEAD
    - npm publish

Important : le pipeline doit avoir les droits d’écrire sur le dépôt. Configurez un token avec les permissions adaptées.

Versioning sémantique

Le lien entre conventional commits et semver est automatique :

Commits                    → Version
feat + fix                 → 1.0.0 → 1.1.0 (minor)
fix seulement              → 1.1.0 → 1.1.1 (patch)
BREAKING CHANGE            → 1.1.1 → 2.0.0 (major)

Automatiser le tout

Mon pipeline final intègre tout :

stages:
  - test
  - release
  - deploy

test:
  stage: test
  script:
    - npm ci
    - npm run lint
    - npm run test

release:
  stage: release
  only:
    - main
  script:
    - npm ci
    - npx standard-version
    - git push --follow-tags origin HEAD
  artifacts:
    paths:
      - CHANGELOG.md

deploy:
  stage: deploy
  script:
    - npm ci
    - npm run build
    - npm run deploy
  needs:
    - release

Conclusion

Les conventional commits et la génération automatique du CHANGELOG ont transformé ma façon de gérer les versions. Plus de notes de release rédigées à la main, plus de commits sans contexte, plus de recherche dans l’historique pour retrouver un changement.

Le CHANGELOG devient un document vivant, précis, et toujours à jour - généré automatiquement à chaque release.

Et vous, comment gérez-vous vos versions et votre CHANGELOG ?