docs: Amélioration du workflow de release dans CLAUDE.md

- Ajout du workflow complet de A à Z (6 phases détaillées)
- Phase 1: Développement sur branche feature
- Phase 2: Préparation de la release (changelog + version)
- Phase 3: Fusion dans main avec --no-ff
- Phase 4: Build des exécutables multi-plateformes
- Phase 5: Documentation finale (notes de release)
- Phase 6: Déploiement en production
- Ajout de la structure finale attendue
- Points de vigilance et bonnes pratiques
- Références à Semantic Versioning et Conventional Commits
This commit is contained in:
Pierre Marx
2025-10-21 11:17:10 -04:00
parent e601fef239
commit 057504a65f

161
CLAUDE.md
View File

@@ -86,35 +86,156 @@ Chaque centre médical a sa propre webview Electron avec :
## Workflow de développement ## Workflow de développement
### Finalisation des modifications ### Workflow complet de release (de A à Z)
Suivre systématiquement ce workflow : Suivre **systématiquement** ce workflow pour chaque nouvelle version :
1. **Mettre à jour le changelog** (`docs/changelog.md`) #### Phase 1 : Développement sur branche feature
- Format date : `AAAA-MM-JJ`
- Catégories : Ajouté, Modifié, Corrigé, Supprimé, Technique, Documentation
2. **Bumper la version** (`package.json`) 1. **Créer une branche feature**
- PATCH (x.x.+1) : Corrections, petits ajustements
- MINOR (x.+1.0) : Nouvelles fonctionnalités compatibles
- MAJOR (+1.0.0) : Changements majeurs
3. **Commit structuré**
```bash ```bash
git add -A git checkout -b feature/nom-de-la-fonctionnalite
git commit -m "type: Description courte ```
- Détail 1 2. **Développer avec commits atomiques**
- Détail 2 - Préfixes : `feat:`, `fix:`, `refactor:`, `docs:`, `style:`, `test:`, `chore:`
- Un commit = une modification logique
- Messages clairs et descriptifs
```bash
git commit -m "feat: Ajouter la fonctionnalité X"
git commit -m "fix: Corriger le bug Y"
git commit -m "refactor: Simplifier le code Z"
```
3. **Tester les modifications**
```bash
npm run dev # Test en mode développement
```
#### 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**
```bash
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" - Bump version X.X.X"
``` ```
**Important** : Ne jamais mentionner Claude, Anthropic ou des adresses emails relatives à ces entités dans les commits
4. **Build si nécessaire** **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**
```bash ```bash
npx electron-builder --linux --x64 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**
```bash
git push origin main
```
#### Phase 4 : Build des exécutables
9. **Build pour les plateformes nécessaires**
```bash
# 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/**
```bash
# 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**
```bash
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**
```bash
scp dist/vX.X.X/SimpleConnect-X.X.X.AppImage user@server:/path/to/app/
```
### Structure finale attendue
Après chaque release, vérifier cette structure :
```
project/
├── docs/
│ └── changelog.md # ✅ Contient la nouvelle version
├── releases/
│ └── vX.X.X.md # ✅ Notes de release détaillées
├── dist/
│ └── vX.X.X/ # ✅ Dossier de version
│ ├── CHANGELOG.md
│ ├── SimpleConnect-X.X.X.AppImage
│ ├── SimpleConnect-X.X.X-arm64.dmg
│ └── SimpleConnect-X.X.X-arm64-mac.zip
└── package.json # ✅ Version à jour
```
### Points de vigilance
- ❌ **Ne JAMAIS committer les binaires dans Git** (`dist/` est dans `.gitignore`)
-**Toujours utiliser --no-ff** pour les merges (historique tracé)
-**Tester avant de merger** dans main
-**Suivre Semantic Versioning** (semver.org)
-**Conventional Commits** pour les messages (conventionalcommits.org)
## Points d'attention ## Points d'attention