Playbook Release

Statut	Actif — v1.0 — 2026-06-27
Priorité	P0
Obligatoire V1	Oui
Responsable	Sylvain
Voir aussi	Playbook Git · Playbook Backup · Release Checklist

Philosophie

Déployer souvent, déployer petit. Une release = un ensemble cohérent de changements qui peuvent être mis en production ensemble.

Le déploiement continu depuis main est la norme. Pas de numéro de version v1.2.3 obligatoire pour les applications web.

Critère de fin de chantier

Un chantier n'est considéré comme terminé que lorsque le code, l'infrastructure, les tests et la documentation sont synchronisés.

Ce n'est pas une formalité — c'est la leçon directe d'un cas réel (2026-07-18) : une documentation de déploiement décrivait une architecture (BASE_PATH=/mon-espace) jamais mise en production, découverte seulement lors d'un audit de continuité PWA sur iOS. Le code, l'infrastructure Cloudflare et la documentation racontaient trois histoires différentes.

Principes :

• Une modification d'architecture doit inclure sa mise à jour documentaire — dans le même chantier, pas « plus tard ».
• Un écart constaté entre la documentation et la production doit être corrigé dès sa détection, pas laissé pour une prochaine passe.
• La documentation doit compiler (npm run build sur dmv-docs) avant toute fusion qui la modifie.
• Les références obsolètes connues (fichier supprimé, route disparue, config changée) doivent être supprimées ou explicitement marquées comme historiques — jamais laissées ambiguës.
• Une release ne doit pas être validée tant que le code, l'infrastructure, les tests et la documentation ne décrivent pas le même état.

Workflow

feature/* ou fix/*
       ↓ PR + CI verte + review
     main
       ↓ push automatique
   production

Le déploiement en production est automatique après merge sur main via GitHub Actions. La CI doit être verte — pas d'exception.

Frontend — Cloudflare Pages

Cloudflare Pages déploie automatiquement à chaque push sur main. Aucune action manuelle requise.

Rollback : Cloudflare Pages → Deployments → sélectionner un déploiement précédent → "Rollback to this deployment". Opérationnel en < 2 minutes.

Preview : chaque PR génère automatiquement un déploiement de preview sur une URL temporaire.

Backend — Laravel sur VPS

Le workflow deploy.yml s'exécute à chaque push sur main :

1. Tests PHPUnit (avec PostgreSQL)
2. Si OK → deploy via SSH :
   • git pull origin main
   • composer install --no-dev
   • Mode maintenance ON
   • php artisan migrate --force
   • Rebuild des caches Laravel
   • Reload PHP-FPM
   • Restart workers Supervisor
   • Mode maintenance OFF

Rollback backend :

# Sur le VPS
cd /srv/dmv/api
git log --oneline -10       # identifier le commit précédent
git checkout <sha>
composer install --no-dev --optimize-autoloader
php artisan config:cache route:cache view:cache
sudo systemctl reload php8.4-fpm
php artisan up

Toujours disposer d'une sauvegarde avant de déclencher un rollback sur une migration.

Hotfix en urgence

Un hotfix suit exactement le même chemin qu'une feature :

fix/correction-urgente → PR → CI → merge main → deploy auto

La CI ne doit jamais être contournée même en urgence. Si la CI est trop lente en urgence, la solution est d'accélérer la CI, pas de la bypasser.

Release notes

Pour les changements significatifs (nouvelle fonctionnalité principale, refactoring), créer une GitHub Release :

Titre : 2026-06-27 — Agenda public et recherche

Corps :
- Ajout de l'agenda public accessible sans connexion
- Amélioration de la recherche d'acteurs
- Correction de l'affichage mobile sur la page mur

Format de date : YYYY-MM-DD. Pas de numéro de version pour les apps web.

Après le déploiement

Vérifications systématiques dans les 10 minutes suivant un déploiement :

• Health check API : curl https://api.monvillage.fr/api/v1/health
• Navigation sur les pages modifiées
• Vérification des logs Nginx (tail -f /var/log/nginx/error.log)
• Vérification des workers Supervisor (supervisorctl status)

En cas d'anomalie → rollback immédiat, diagnostic ensuite.

Environnements

Environnement	Branche	Déploiement
Production	main	Automatique via CI
Preview	PR	Cloudflare Pages preview (frontend)
Local	—	npm run dev / php artisan serve

Pas d'environnement de staging permanent obligatoire. Les previews Cloudflare Pages suffisent pour le frontend. Pour le backend, tester en local avec une base de test.

Checklist complète

Voir la Release Checklist pour les vérifications avant chaque release importante.