Release & Déploiement

Ce chapitre détaille le processus de release et les différentes stratégies de déploiement selon l’environnement cible.

Processus de Release

Le processus de release est déclenché manuellement via GitHub Actions (workflow_dispatch) :

1. Déclencheur : execution manuelle du workflow avec un input de version (patch, minor, major ou 1.2.3)
2. Préparation : bump des versions dans les 3 package.json via bumpp
3. Build : création des images Docker pour les 3 applications
4. Publication : push des images taguées dans le registry Github en privé
5. Commit & Tag : commit des changements de version + création du tag Git
6. GitHub Release : création de la release GitHub avec le changelog généré par git-cliff

Le tag Git est créé après le build réussi, pas avant. Cela garantit que le tag pointe toujours vers du code qui a été buildé et testé.

Versionnement

Le projet suit Semantic Versioning :

• MAJOR : changement breakant l’API
• MINOR : nouvelle fonctionnalité backward-compatible
• PATCH : correction de bug

Environnements

Développement

L’environnement de développement est déployé automatiquement via Coolify. À chaque push sur la branche main, Coolify détecte le changement et lance un build direct depuis le dépôt Git.

GitHub (push main)
    │
    ▼ webhook
Coolify dev
    ├── server    (build auto)
    ├── web-agri  (build auto)
    └── web-pilots (build auto)

Cet environnement sert aux tests d’intégration et au développement quotidien.

Production

La production n’est déployée qu’à partir de tags Git validés. L’image Docker est prébuildée par le workflow de release, puis déployée par Coolify.

Keep a Changelog

Le projet utilise git-cliff pour maintenir un historique clair des changements. Le changelog est généré automatiquement lors de la création de la release GitHub, en se basant sur les commits depuis la dernière release.