Files
SimpleClient-releases/.claude/commands/dev.md
2025-10-21 14:21:16 -04:00

5.4 KiB

Workflow complet de développement (de A à Z)

Suivre systématiquement ce workflow pour chaque nouvelle fonctionnalité ou correction de bug :

Phase 1 : Développement itératif

Principe : Petit à petit, commit par commit

Une fonctionnalité = plusieurs petits commits atomiques

Éviter de faire un gros commit avec toute la fonctionnalité. Préférer découper en petites étapes testables :

Exemple : Ajouter un bouton "Pause" avec confirmation

❌ MAUVAIS : 1 gros commit
git commit -m "feat: Ajouter bouton Pause avec modal et gestion IPBX"

✅ BON : 5 petits commits
1. feat: Ajouter le bouton Pause dans le header
2. style: Ajouter l'icône SVG pour le bouton Pause
3. feat: Implémenter la modal de confirmation
4. feat: Connecter le bouton à SignalR pour pause IPBX
5. docs: Documenter la fonctionnalité de pause

1. Créer une branche feature

git checkout -b feature/nom-de-la-fonctionnalite

2. Cycle itératif (répéter jusqu'à complétion de la fonctionnalité)

Pour chaque petite modification :

a) Développer une petite partie

  • Faire UNE modification logique à la fois
  • Ne pas chercher à tout finir d'un coup
  • Rester concentré sur une seule tâche

b) Tester

IMPORTANT : Toujours tester AVANT de committer

npm run dev  # Test en mode développement
  • Vérifier que la modification fonctionne
  • Tester les cas limites
  • S'assurer qu'aucune régression n'a été introduite

c) Committer (commit atomique)

Seulement après avoir testé avec succès :

  • Préfixes : feat:, fix:, refactor:, docs:, style:, test:, chore:
  • Un commit = une modification logique
  • Messages clairs et descriptifs
git commit -m "feat: Ajouter le bouton Pause dans le header"

Pourquoi tester avant de committer ?

  • Historique Git propre (chaque commit = code fonctionnel)
  • Rollback facile vers un état stable
  • git bisect fonctionne correctement

d) Continuer

Retour à l'étape a) pour la prochaine petite modification, jusqu'à ce que la fonctionnalité soit complète.

3. Fonctionnalité terminée → Passer à la Phase 2 (Release)

Une fois tous les commits de la fonctionnalité effectués, passer à la préparation de la release ci-dessous.

Exception - WIP commits (travail en cours à sauvegarder) :

git commit -m "wip: Travail en cours sur la fonctionnalité X"
# Plus tard, après tests réussis :
git commit --amend -m "feat: Ajouter la fonctionnalité X"

Phase 2 : Préparation de la release

4. Mettre à jour le changelog (docs/changelog.md)

  • Obtenir la date : date +%Y-%m-%d
  • Format : ## [X.X.X] - AAAA-MM-JJ
  • Catégories : Ajouté, Modifié, Corrigé, Supprimé, Technique, Documentation
  • Ajouter en haut du fichier (au-dessus de la version précédente)

5. Bumper la version (package.json)

  • PATCH (x.x.+1) : Corrections, petits ajustements
  • MINOR (x.+1.0) : Nouvelles fonctionnalités compatibles
  • MAJOR (+1.0.0) : Changements majeurs incompatibles
  • Modifier le champ "version": "X.X.X"

6. Commit de release

git add docs/changelog.md package.json
git commit -m "release: Version X.X.X - Titre court

- Fonctionnalité 1
- Fonctionnalité 2
- Correction 1
- Bump version X.X.X"

Important : Ne jamais mentionner Claude, Anthropic ou des adresses emails relatives à ces entités


Phase 3 : Fusion dans main

7. Basculer sur main et fusionner

git checkout main
git merge feature/nom-de-la-fonctionnalite --no-ff
  • --no-ff : Force un merge commit (historique propre et tracé)

8. Push vers origin

git push origin main

Phase 4 : Build des exécutables

9. Build pour les plateformes nécessaires

# macOS (si développement sur Mac)
npm run build

# Linux x64 (production principale)
npm run build:linux-x64

# Windows (si nécessaire)
npm run build:win

10. Organiser les builds dans dist/vX.X.X/

# Créer le dossier de version
mkdir -p dist/vX.X.X

# Copier le changelog
cp docs/changelog.md dist/vX.X.X/CHANGELOG.md

# Déplacer les builds
mv dist/SimpleConnect-X.X.X*.{AppImage,dmg,zip,exe} dist/vX.X.X/ 2>/dev/null
mv dist/SimpleConnect-X.X.X*.blockmap dist/vX.X.X/ 2>/dev/null

# Vérifier le contenu
ls -lh dist/vX.X.X/

Phase 5 : Documentation finale

11. Créer les notes de release (releases/vX.X.X.md)

  • Structure markdown avec sections :
    • Titre et date
    • Résumé des changements
    • Nouveautés principales
    • Corrections
    • Fichiers disponibles
    • Compatibilité
    • Guide d'utilisation (si nécessaire)

12. Commit et push de la documentation

git add releases/vX.X.X.md
git commit -m "docs: Ajout des notes de release pour vX.X.X"
git push origin main

Phase 6 : Déploiement (optionnel)

13. Déployer sur le serveur de production

scp dist/vX.X.X/SimpleConnect-X.X.X.AppImage user@server:/path/to/app/

Résumé du workflow

1. git checkout -b feature/XXX
2. BOUCLE (jusqu'à fonctionnalité complète) :
   a) Développer une petite partie
   b) Tester (npm run dev)
   c) Committer (git commit -m "...")
   d) Continuer
3. Mettre à jour changelog
4. Bumper version package.json
5. Commit de release
6. Merger dans main (--no-ff)
7. Push
8. Build
9. Organiser dist/
10. Notes de release
11. Commit + push docs
12. Déployer (optionnel)