Conventions Git

Nous utilisons les commits conventionnels (feat:, fix:, chore:) qui génèrent automatiquement les changelogs. Les branches sont nommées d'après les tickets : feat/ZENO-123-add-heatmaps.

Les messages de commit doivent être à l'impératif (« Ajouter les cartes de chaleur » pas « Cartes de chaleur ajoutées ») et expliquer pourquoi, pas seulement quoi. Le diff montre ce qui a changé — votre message doit expliquer le raisonnement.

Pull requests

Chaque changement passe par une revue de code. Les PR doivent être petites, ciblées et inclure du contexte pour les réviseurs. Nous visons des revues dans les 4 heures pendant les heures de travail.

Exigences des PR :

Tous les tests passent
La vérification des types réussit
Au moins une approbation
Pas de commentaires non résolus

Les bonnes descriptions de PR incluent : ce qui a changé, pourquoi ça a changé, comment le tester et tout risque ou travail de suivi nécessaire.

Pipeline CI/CD

Chaque push déclenche notre pipeline CI : lint, vérification des types, test, build. Les fusions vers main se déploient automatiquement en staging. Les déploiements en production nécessitent une approbation explicite.

Le pipeline s'exécute en moins de 5 minutes. S'il prend plus longtemps, nous le traitons comme un bug à corriger. Des boucles de feedback rapides maintiennent les développeurs productifs.

Gestion des environnements

Nous maintenons trois environnements :

Développement : Machines locales avec Wrangler pour les Workers et Supabase local.
Staging : Environnement similaire à la production sur des sous-domaines de staging. Utilisé pour le contrôle qualité final et les démos.
Production : Le vrai système. Déployé après vérification en staging et approbation explicite.

Migrations de base de données

Les changements de schéma passent par les migrations Supabase. Chaque migration doit être réversible avec une migration inverse correspondante. Nous testons les migrations en staging avec des données similaires à la production avant de les appliquer en production.

Processus de release

Nous livrons en continu. Les fonctionnalités sont mises en ligne dès qu'elles sont prêtes, protégées par des feature flags. Les changements majeurs sont annoncés dans notre changelog avec des guides de migration clairs.

Les feature flags nous permettent de déployer du code sans l'activer pour les utilisateurs. Cela signifie des releases plus sûres, des déploiements progressifs et des retours en arrière faciles si quelque chose tourne mal.