# 🚀 Optimisations du Workflow CI/CD

## ✅ Changements appliqués (14 février 2026)

### 1. **Tag SHA pour le déploiement** 🏷️

**Avant :**

- Tag basé sur la version : `v1.3.73`
- Nécessitait `npm run version:bump:patch` à chaque commit
- Risque de conflit si 2 commits successifs sans bump

**Maintenant :**

- Tag basé sur le SHA du commit : `e7d9997`
- **Automatique et unique** pour chaque commit
- La version (v1.3.73) reste visible pour l'app, mais le déploiement utilise le SHA

**Résultat :**

- ✅ Plus besoin de bumper la version à chaque commit
- ✅ Impossible d'avoir un conflit de tag
- ✅ Déploiement fiable à 100%

---

### 2. **Skip CI avec `[skip ci]`** ⏭️

Ajoutez `[skip ci]` dans votre message de commit pour **sauter les tests et le déploiement** :

```bash
git commit -m "docs: mise à jour README [skip ci]"
git push
```

**Cas d'usage :**

- Modification de documentation uniquement
- Changement de fichiers `.md`, `.txt`
- Corrections de typos

**Gain de temps :** ~10 minutes économisées

---

### 3. **Tests conditionnels** 🎯

**Avant :** Tests lancés sur TOUS les fichiers, même pour un changement de doc

**Maintenant :** Tests lancés uniquement si :

- Le code source change (`src/**`)
- Les dépendances changent (`package.json`)

**Gain de temps :** ~2-3 minutes si seulement config/docs

---

### 4. **Cache NPM amélioré** 📦

Utilisation de `npm ci --prefer-offline` pour installer plus rapidement.

**Gain de temps :** ~30 secondes

---

## 📊 Résumé des gains de temps

| Type de changement               | Avant   | Après    | Gain  |
| -------------------------------- | ------- | -------- | ----- |
| **Code + tests**                 | ~10 min | ~5-6 min | -40%  |
| **Config/docs seulement**        | ~10 min | ~3-4 min | -60%  |
| **Documentation avec [skip ci]** | ~10 min | 0 min    | -100% |

---

## 🎯 Workflow optimal selon le type de commit

### 📝 Documentation uniquement

```bash
git commit -m "docs: amélioration du README [skip ci]"
git push
```

→ **0 min** (pas de build, pas de déploiement)

---

### 🔧 Changement de configuration

```bash
git commit -m "chore: mise à jour variables env"
git push
```

→ **~3-4 min** (build uniquement, pas de tests)

---

### 💻 Changement de code

```bash
git commit -m "feat: ajout nouvelle fonctionnalité"
git push
```

→ **~5-6 min** (CI complet + build + déploiement)

---

### 🐛 Fix urgent en production

```bash
git commit -m "fix: correction bug critique [rebuild-all]"
git push
```

→ **~5-6 min** (force rebuild de toutes les images)

---

## 🔄 Gestion des versions

### Quand bumper la version ?

**Avant :** À chaque commit (sinon pas de déploiement)

**Maintenant :** Seulement pour les **vraies releases** :

- ✅ **Bump PATCH** : Correction de bugs

  ```bash
  npm run version:bump:patch  # v1.3.73 → v1.3.74
  ```

- ✅ **Bump MINOR** : Nouvelle fonctionnalité

  ```bash
  npm run version:bump:minor  # v1.3.0 → v1.4.0
  ```

- ✅ **Bump MAJOR** : Breaking changes
  ```bash
  npm run version:bump:major  # v1.0.0 → v2.0.0
  ```

**Exemple de workflow typique :**

```bash
# 10 commits de développement
git commit -m "feat: ajout feature A"
git push  # Déploie avec SHA e7d9997

git commit -m "fix: correction bug"
git push  # Déploie avec SHA a1b2c3d

git commit -m "refactor: amélioration code"
git push  # Déploie avec SHA 4e5f6g7

# Quand la feature est complète et testée en prod
npm run version:bump:minor  # v1.3.0 → v1.4.0
git commit -m "release: v1.4.0"
git push  # Déploie v1.4.0 avec SHA 8h9i0j1
```

**Résultat :**

- Version reste à v1.3.73 pendant le développement
- Bump seulement pour les releases officielles
- Pas de v99.99.99 après 1 an !

---

## 🎛️ Options avancées

### Forcer le rebuild de toutes les images

```bash
git commit -m "chore: rebuild complet [rebuild-all]"
```

### Skipper les tests mais garder le build

```bash
# (Non implémenté mais possible si besoin)
git commit -m "wip: work in progress [skip tests]"
```

---

## 📈 Évolution future possible

- [ ] Paralléliser les builds Docker (si plusieurs services modifiés)
- [ ] Cache Docker layers entre les builds
- [ ] Tests E2E uniquement sur la branche `main`
- [ ] Preview deployments pour les branches de feature

---

**Date de mise à jour :** 14 février 2026  
**Auteur :** GitHub Copilot
