Le workflow de développement

Le projet Charly repose sur un workflow de développement collaboratif et un système CI/CD robuste pour livrer de nouvelles fonctionnalités de manière efficace. L'équipe, composée d'Alexandre Trotel (Lead Tech & Monorepo/DX), Ayoub Barich (Backend, Scraping & DevOps), et Laurent Cocault (Scraping & Architecture), travaille ensemble dans un monorepo géré avec Git, Turborepo. Ce workflow orchestre le développement, les tests, et les déploiements des composants du projet : l'application web (apps/web), le scraping (apps/cli), et la base de données (packages/db). Cette page décrit comment l'équipe collabore, les workflows Git, et le pipeline CI/CD adapté à ces composants.

Organisation de l'équipe

L'équipe est structurée pour maximiser la collaboration tout en respectant les domaines d'expertise de chacun :

• Alexandre Trotel (Lead Tech & Monorepo/DX) : Responsable du frontend web (apps/web), et de la gestion de la base de données (packages/db). Il définit les schémas de la base de données, synchronise les migrations, et supervise l'intégration des composants. Il gère également la configuration du monorepo avec Turborepo et optimise l'expérience de développement (DX) via des outils et des scripts partagés.
• Ayoub Barich (Backend, Scraping & DevOps) : Conçoit et maintient les endpoints ORPC dans apps/web/src/rpc, en veillant à leur intégration avec la base de données et à leur performance. Il contribue également aux scripts de scraping (apps/cli) pour extraire des données (ex. Eventbrite) et gère les aspects DevOps, incluant la configuration CI/CD et l'infrastructure de déploiement.
• Thomas Roux (Frontend Mobile) : Développe l'application mobile, en consommant l'API backend et en utilisant les types partagés (packages/shared) pour assurer la cohérence avec le frontend web.
• Laurent Cocault (Scraping & Architecture) : Développe les scripts de scraping (apps/cli) pour extraire des données (ex. Eventbrite) et contribue à l'architecture globale, en optimisant les flux de données et les performances.

L'équipe utilise GitHub pour la gestion du code, les issues, et les pull requests.

Workflow de développement

Le workflow de développement est basé sur un modèle simplifié utilisant Git, avec des branches créées pour chaque issue GitHub associée au monorepo. Un environnement de staging sera mis en place ultérieurement pour tester les changements avant le déploiement en production. Les releases et les tags ne sont pas utilisés pour l'instant afin de réduire la complexité.

1. Structure des branches

• La branche principal : Branche principale main contenant le code stable et déployable. Chaque fusion dans main déclenche un déploiement via CI/CD.
• Branches par issue : Nommées <numero>-<description> (ex. 42-add-reviews-table), créées pour chaque tâche ou correction liée à une issue GitHub.

2. Workflow Git

1. Créer une branche pour une issue :

   • Identifiez une issue sur GitHub (ex. #42 : Ajouter une table reviews).

   • Créez une branche à partir de main :

     git checkout main
     git pull origin main
     git checkout -b 42-add-reviews-table

   • Chaque membre travaille sur son domaine : Alexandre sur le frontend web, la base de données, ou le backend ; Thomas sur le mobile ; Ayoub sur le backend ; Laurent sur le scraping.

2. Développer et tester localement :

   • Utilisez les scripts Turborepo pour lancer les composants localement :

     bun run dev:web    # Web (Alexandre, Ayoub)
     bun run db:push    # Synchroniser la base de données (Alexandre)

   • Laurent exécute les scripts de scraping (apps/cli/src/index.ts) pour valider les données extraites.

3. Valider les changements :

   • Exécutez les tests et le linter :

     bun run test
     bun run lint

   • Assurez-vous que votre branche est synchronisée avec la branche principale de manière régulière avec git pull origin main.

WARNING

C'est pas grave si le linting passe pas pour l'instant.

4. Commit et push :

   • Utilisez des messages de commit clairs, suivant la convention Conventional Commits :

     git commit -m "feat: add reviews table and endpoint"
     git push origin 42-add-reviews-table

5. Ouvrir une pull request (PR) :

   • Créez une PR sur GitHub depuis <numero>-<description> vers main.
   • Ajoutez une description détaillée, incluant les changements dans la base de données, le backend, le frontend, ou le scraping.
   • Assignez au moins un relecteur : Alexandre pour les changements globaux ou liés à la base de données, Laurent pour le scraping ou l'architecture. Pour les petits débogages, Copilot peut assister dans la revue initiale.
   • Liez la PR à l'issue correspondante (ex. #42).

6. Revue et fusion :

   • Le relecteur (Alexandre ou Laurent) vérifie le code, demande des modifications si nécessaire, et approuve la PR.
   • Une fois approuvée, la PR est fusionnée dans main, déclenchant les tests CI/CD.
   • L'issue associée est automatiquement fermée si elle est référencée dans la PR (ex. Closes #42).

3. Collaboration dans le monorepo

• Base de données : Alexandre définit et maintient les schémas dans packages/db/src/schema/ et synchronise avec db:push ou db:migrate. Ayoub utilise ces schémas pour les requêtes backend, et Laurent pour valider les données scrapées.
• Backend : Alexandre et Ayoub développent les endpoints ORPC (apps/web/src/rpc/procedures/), partagés avec le frontend via @charly/shared.
• Frontend web : Alexandre construit les composants React et les hooks SWR (apps/web/src/hooks/), en s'assurant que les types correspondent à ceux du backend.
• Scraping : Laurent développe les scripts dans apps/cli/src/ pour extraire des données, qui sont validées avec les schémas Zod et publiées dans la base de données.

Les packages partagés (packages/db, packages/shared) facilitent la réutilisation du code et des types, réduisant les incohérences. Turborepo orchestre les builds et tests avec des commandes comme bun run build ou bun run test.

Adaptations spécifiques à Charly

• Base de données :

  • Les migrations sont appliquées manuellement via bun run db:migrate avant le déploiement en production, ou via db:push en développement (Alexandre).
  • Le fichier packages/db/.env doit contenir DATABASE_URL pour la base de données de production.
  • Alexandre valide les schémas (packages/db/src/schema/) dans les PR pour éviter les conflits.

• Backend :

  • Les endpoints oRPC sont testés avec bun run test dans le pipeline CI.
  • Ayoub s'assure que les changements dans apps/web/src/rpc/procedures/ sont rétrocompatibles.

• Frontend web :

  • Les builds Vite (apps/web) sont testés pour la compatibilité avec Vercel et Docker.
  • Alexandre vérifie les hooks SWR (apps/web/src/hooks/) pour garantir l'intégration avec le backend.

• Frontend mobile :

  • Thomas intègre des tests spécifiques pour l'application mobile, exécutés séparément (non inclus dans le workflow actuel, mais planifiés pour un futur pipeline).
  • Les types partagés (packages/shared) garantissent la cohérence avec le frontend web.

• Scraping :

  • Les scripts de scraping (apps/cli) sont exclus du déploiement Docker (voir .dockerignore), car ils sont exécutés manuellement ou via des jobs planifiés.
  • Laurent teste les scripts localement et valide les données extraites dans la base de données avec bun run db:studio.

Tests dans le pipeline

Le pipeline exécute automatiquement :

• Tests unitaires : Avec Jest pour apps/cli (bun run test).
• Linting : Avec ESLint pour vérifier la qualité du code (bun run lint).
• Builds : Avec Turborepo pour s'assurer que tous les composants se construisent correctement (bun run build).

Les tests de la base de données (ex. validation des schémas Zod) sont effectués localement par Alexandre avant la fusion des PR.

Bonnes pratiques

• Commits clairs : Utilisez Conventional Commits pour faciliter la traçabilité (ex. feat, fix, docs).
• PR détaillées : Incluez des descriptions des changements dans la base de données, le backend, le frontend, ou le scraping, avec des captures d'écran si pertinent.
• Tests locaux : Exécutez bun run test et git pull origin main avant de pousser une branche.
• Validation des déploiements : Vérifiez les images Docker sur DockerHub après un push réussi.
• Revue rigoureuse : Assurez-vous qu'Alexandre ou Laurent revoit chaque PR, avec Copilot pour accélérer les petits débogages.