Engineering Workflow


Statut	Actif — v1.0 — 2026-06-27
Priorité	P0
Responsable	Sylvain
Voir aussi	Standards · Playbook Git · Playbook CI · Playbook Release

Ce document est la porte d'entrée de l'Engineering Handbook. Il décrit le cycle de vie complet d'une évolution sur DMV, de l'idée au déploiement.

Vue d'ensemble

  IDÉE
   │
   ▼
┌─────────────────────────┐
│  1. Créer une branche   │  feature/* ou fix/*
└─────────────┬───────────┘
              │
   ▼
┌─────────────────────────┐
│  2. Développer          │  Standards de code
└─────────────┬───────────┘
              │
   ▼
┌─────────────────────────┐
│  3. Vérifier en local   │  lint · typecheck · tests
└─────────────┬───────────┘
              │
   ▼
┌─────────────────────────┐
│  4. Ouvrir une PR       │  titre · description
└─────────────┬───────────┘
              │
   ▼
┌─────────────────────────┐
│  5. CI automatique      │  lint · typecheck · build · tests · sécurité
└─────────────┬───────────┘
              │ ✅ CI verte
   ▼
┌─────────────────────────┐
│  6. Revue de code       │  1 approbateur minimum
└─────────────┬───────────┘
              │ ✅ Approuvé
   ▼
┌─────────────────────────┐
│  7. Merge sur main      │  squash and merge
└─────────────┬───────────┘
              │
   ▼
┌─────────────────────────┐
│  8. Déploiement auto    │  CF Pages / VPS via GitHub Actions
└─────────────┬───────────┘
              │
   ▼
┌─────────────────────────┐
│  9. Monitoring          │  health check · logs · workers
└─────────────┬───────────┘
              │ ✅ Tout OK
   ▼
┌─────────────────────────┐
│ 10. Release notes       │  si changement significatif
└─────────────────────────┘

Étapes en détail

1. Créer une branche

Toujours partir d'un main à jour.

git checkout main
git pull origin main
git checkout -b feature/ma-fonctionnalite

Convention : feature/<sujet> ou fix/<sujet>. Minuscules, tirets, 4-5 mots max.

→ Playbook Git — Nommage des branches

2. Développer

Respecter les standards pendant le développement, pas après.

TypeScript strict — pas de any
Pas de duplication — chercher le composant ou le service existant
Commits réguliers et lisibles : Ajoute la page agenda publique

→ Standards DMV

3. Vérifier en local

Avant de pousser, s'assurer que la CI passera.

Frontend

npm run lint
npm run typecheck
npm run build

Backend

vendor/bin/pint --test
php artisan test

Un build cassé ou des erreurs de types ne doivent jamais atteindre la CI.

→ Standards — Tableau de bord qualité

4. Ouvrir une Pull Request

git push -u origin feature/ma-fonctionnalite
# → Ouvrir la PR sur GitHub

Titre : même convention que les commits.
Description : ce que fait la PR + comment tester si ce n'est pas évident.

Pas besoin d'une PR parfaite — une PR lisible suffit.

→ Playbook Git — Pull Requests

5. CI automatique

GitHub Actions lance automatiquement :

Job	Ce qu'il vérifie
Lint	Qualité du code (ESLint / Pint)
Typecheck	Cohérence des types TypeScript
Build	Le build ne régresse pas
Tests	PHPUnit / Playwright
Security	Secrets, dépendances vulnérables

La CI doit être verte pour merger. Sans exception.

Si la CI est rouge → corriger la cause, pas contourner le check.

→ Playbook CI

6. Revue de code

Au moins 1 approbateur avant le merge. La revue porte sur :

Logique et correctitude
Respect des standards
Cas limites non gérés
Lisibilité

Une revue n'est pas une recherche d'imperfections stylistiques — c'est une vérification que le code fait ce qu'il est censé faire.

→ Playbook Git — Pull Requests

7. Merge sur main

Squash and merge — un commit propre par fonctionnalité dans l'historique.

La branche est supprimée après le merge.

8. Déploiement automatique

Le push sur main déclenche automatiquement le déploiement.

Projet	Plateforme	Délai
dmv-public, dmv-workspace	Cloudflare Pages	~2 min
api (Laravel)	VPS via SSH	~5 min

Suivre le workflow GitHub Actions jusqu'à la fin.

→ Playbook Release — Déploiement

9. Monitoring post-déploiement

Dans les 10 minutes suivant le déploiement :

# Health check API
curl https://api.monvillage.fr/api/v1/health

# Vérifier les workers
sudo supervisorctl status

# Vérifier les logs
sudo tail -n 50 /var/log/nginx/error.log

Tester manuellement les pages ou parcours modifiés.

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

→ Playbook Monitoring · Playbook Release — Rollback

10. Release notes

Pour les changements significatifs, créer une GitHub Release :

2026-06-27 — Agenda public et recherche

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

Pas de release note pour les bug fixes courants.

→ Playbook Release — Release notes

En cas de doute

Situation	Référence
Je ne sais pas comment nommer ma branche	Playbook Git
La CI est rouge et je ne comprends pas pourquoi	Playbook CI
J'ai besoin de déployer en urgence	Playbook Release — Hotfix
Je dois vérifier qu'une release est safe	Release Checklist
Je découvre un problème en production	Playbook Monitoring

Vue d'ensemble​

Étapes en détail​

1. Créer une branche​

2. Développer​

3. Vérifier en local​

4. Ouvrir une Pull Request​

5. CI automatique​

6. Revue de code​

7. Merge sur main​

8. Déploiement automatique​

9. Monitoring post-déploiement​

10. Release notes​

En cas de doute​