CI/CD Pipeline

1.1 Objectif du Document

Ce document définit l'architecture et les procédures du pipeline CI/CD (Continuous Integration / Continuous Deployment) de la plateforme REWAPP. Il constitue la référence pour l'équipe de développement concernant l'automatisation des builds, tests, et déploiements.

1.2 Portée

Le pipeline CI/CD couvre l'ensemble des composantes de l'écosystème REWAPP :

• Application Mobile - Angular + Ionic
• Site Vitrine - Next.js
• Dashboard Admin - React + Vite
• Dashboard Partenaire - React PWA + Vite
• Backend API - NestJS microservices
• Infrastructure Cloud - CapRover via Docker

1.3 Documents de Référence

• 4.1 Architecture Technique Globale
• 4.5 Stack Technique Détaillé
• 10.1 Plan de Déploiement
• 10.2 Documentation Technique Ops
• 8.1 Plan de Tests Global

2.1 Vue d'Ensemble

L'architecture CI/CD de REWAPP repose sur une approche GitOps où le code source, la configuration et l'infrastructure sont gérés via Git. Chaque modification déclenche automatiquement les pipelines appropriés.

2.2 Principes Directeurs

2.3 Outils et Technologies

3.1 Déclencheurs du Pipeline

3.2 Étapes du Pipeline CI

Le pipeline CI s'exécute en plusieurs étapes séquentielles et parallèles pour optimiser le temps d'exécution :

3.3 Tests Automatisés

3.3.1 Tests Unitaires

3.3.2 Tests d'Intégration

• Tests API avec Supertest : Validation des endpoints REST
• Tests base de données : Migrations, seeds, queries critiques
• Tests services externes : Mocks des intégrations tierces

3.3.3 Tests End-to-End (E2E)

3.4 Analyse de Qualité du Code

3.4.1 ESLint Configuration

Règles principales appliquées :

• @typescript-eslint/recommended : Règles TypeScript strictes
• eslint-plugin-react : Bonnes pratiques React
• eslint-plugin-react-hooks : Règles des hooks
• eslint-plugin-import : Organisation des imports
• eslint-plugin-security : Règles de sécurité

3.4.2 SonarQube Quality Gates

3.5 Scan de Sécurité

3.5.1 Analyse des Dépendances

• npm audit : Audit des packages npm (bloquant sur vulnérabilités critiques)
• Snyk : Scan approfondi avec base de données vulnérabilités étendue
• License check : Vérification des licences compatibles

3.5.2 Analyse des Images Docker

• Trivy : Scan des images Docker pour vulnérabilités OS et packages
• Docker Scout : Analyse des couches et recommandations

4.1 Stratégie de Déploiement

REWAPP utilise une stratégie de déploiement Blue-Green pour garantir des déploiements sans interruption de service et permettre des rollbacks instantanés.

4.2 Workflow de Déploiement

4.2.1 Déploiement Développement (Automatique)

4.2.2 Déploiement Staging (Automatique)

4.2.3 Déploiement Production (Manuel avec Approbation)

4.3 Déploiement Blue-Green

4.3.1 Architecture Blue-Green

• Blue : Environnement de production actif
• Green : Nouvel environnement avec la nouvelle version
• ALB (Application Load Balancer) : Bascule du trafic entre Blue et Green

4.3.2 Processus de Bascule

4.3.3 Critères de Rollback Automatique

4.4 Gestion des Rollbacks

4.4.1 Rollback Automatique

Le rollback automatique est déclenché lorsque les seuils définis sont dépassés pendant la fenêtre d'observation post-déploiement.

4.4.2 Rollback Manuel

Commande de rollback manuel :

• Via GitHub Actions : Workflow "Rollback Production"
• Sélection de la version cible (tag précédent)
• Confirmation par un membre de l'équipe ops
• Temps d'exécution : < 5 minutes

5.1 Configuration des Environnements

5.2 Promotion entre Environnements

5.2.1 Flux de Promotion

5.2.2 Critères de Promotion

5.3 Gestion des Secrets

5.3.1 Gestion des Secrets CapRover

Tous les secrets sont stockés dans les variables d'environnement CapRover avec les conventions suivantes :

• Nommage : rewapp/{environnement}/{service}/{secret}
• Exemple : rewapp/production/api/database-url

5.3.2 Secrets par Environnement

5.3.3 Rotation des Secrets

• Secrets critiques (JWT, API keys) : Rotation automatique tous les 90 jours
• Credentials base de données : Rotation tous les 30 jours
• Notification : 7 jours avant expiration

6.1 Structure des Workflows

Organisation des fichiers :

.github/
├── workflows/
│   ├── ci.yml                    # Pipeline CI principal
│   ├── cd-dev.yml                # Déploiement développement
│   ├── cd-staging.yml            # Déploiement staging
│   ├── cd-production.yml         # Déploiement production
│   ├── rollback.yml              # Rollback manuel
│   ├── mobile-build.yml          # Build app mobile (EAS)
│   ├── terraform-plan.yml        # Plan infrastructure
│   ├── terraform-apply.yml       # Apply infrastructure
│   └── security-scan.yml         # Scan de sécurité hebdomadaire
└── actions/
    ├── setup-node/               # Action réutilisable Node.js
    ├── docker-build/             # Action build Docker
    └── deploy-caprover/          # Action déploiement CapRover

6.2 Workflow CI Principal

6.3 Workflow de Déploiement

6.4 Workflows Spécifiques par Application

6.4.1 Application Mobile (Ionic + Capacitor)

6.4.2 Site Vitrine (Vercel)

7.1 Organisation du Code Terraform

Structure des répertoires :

infrastructure/
├── modules/
│   ├── network/             # Configuration Réseau
│   ├── docker/              # Containers Docker
│   ├── postgres/            # Base de données PostgreSQL
│   ├── redis/               # Redis Container
│   ├── traefik/             # Reverse Proxy Traefik
│   ├── minio/               # Stockage S3-compatible
│   ├── nginx/               # Serveur Web/CDN
│   └── monitoring/          # Prometheus, Grafana, alertes
├── environments/
│   ├── dev/
│   │   ├── docker-compose.yml
│   │   └── .env
│   ├── staging/
│   └── production/
└── global/
    ├── caprover/            # Configuration CapRover
    ├── registry/            # Docker Registry
    └── dns/                 # Configuration DNS

7.2 Modules Réutilisables

7.3 Pipeline Terraform

7.3.1 Workflow Terraform Plan

7.3.2 Workflow Terraform Apply

8.1 Stratégie de Build Docker

8.1.1 Multi-stage Builds

Toutes les images utilisent des builds multi-stage pour optimiser la taille :

8.1.2 Images de Base

8.2 Docker Registry

8.2.1 Repositories Docker

8.2.2 Scan de Vulnérabilités Docker

• Scan automatique à chaque push d'image
• Blocage du déploiement si vulnérabilités critiques détectées
• Rapport de scan disponible dans les logs CI/CD

8.3 Tagging des Images

9.1 Contrôle d'Accès

9.1.1 Permissions GitHub

9.1.2 Service Accounts CapRover

• CI/CD assume un rôle IAM dédié avec permissions minimales
• Principe du moindre privilège appliqué
• Pas de credentials long-terme, utilisation OIDC avec GitHub

9.2 Audit et Traçabilité

9.2.1 Logs d'Audit

• GitHub Audit Log : Toutes les actions sur les repositories
• CapRover Logs : Toutes les actions (déploiements, modifications)
• Rétention : 90 jours minimum, archivage S3 Glacier au-delà

9.2.2 Traçabilité des Déploiements

9.3 Protection des Branches

9.3.1 Règles de Protection

9.3.2 Code Owners

Fichier CODEOWNERS définissant les reviewers obligatoires :

/infrastructure/*  → équipe DevOps
/apps/api/*        → équipe Backend
/apps/mobile/*     → équipe Mobile
/.github/*         → équipe DevOps

10.1 Métriques CI/CD

10.2 Notifications et Alertes

10.2.1 Canaux de Notification

10.2.2 Format des Notifications

10.3 Rapports de Build

10.3.1 Rapports Automatiques

• Rapport de couverture de tests (Codecov)
• Rapport SonarQube (qualité et sécurité)
• Rapport de vulnérabilités (Snyk)
• Rapport de performance des builds

10.3.2 Dashboard CI/CD

Dashboard Grafana avec métriques :

• Temps de build moyen par application
• Taux de succès par branche
• Fréquence des déploiements
• Historique des incidents

11.1 Procédure de Release

11.1.1 Préparation de Release

1. 1

   Vérification

   S'assurer que tous les tests passent sur staging

2. 2

   QA

   Compléter les tests de QA manuels

3. 3

   Documentation

   Rédiger les release notes

4. 4

   PR

   Créer la PR de release (develop vers main si nécessaire)

5. 5

   Approbations

   Obtenir les approbations requises

11.1.2 Exécution de Release

# Créer le tag
git tag -a release/vX.X.X -m "Release vX.X.X"

# Pousser le tag
git push origin release/vX.X.X

1. 3

   Le workflow de déploiement se déclenche automatiquement

2. 4

   Attendre l'approbation des 2 reviewers dans GitHub

3. 5

   Approuver le déploiement

4. 6

   Surveiller le déploiement et les métriques

5. 7

   Valider le déploiement après la période d'observation (15 min)

11.1.3 Post-Release

• Mettre à jour le changelog
• Communiquer en interne (Slack #releases)
• Archiver les release notes
• Planifier la rétrospective si problèmes rencontrés

11.2 Hotfix en Production

11.2.1 Procédure Hotfix

1. 1

   Créer une branche hotfix/description depuis main

2. 2

   Implémenter le correctif

3. 3

   Tests automatisés (CI)

4. 4

   Code review accéléré (1 approbation minimum)

5. 5

   Merge vers main

6. 6

   Création immédiate du tag hotfix/vX.X.X

7. 7

   Déploiement avec processus accéléré (1 approbateur)

8. 8

   Merge retour vers develop

11.2.2 Critères de Hotfix

11.3 Maintenance du Pipeline

11.3.1 Maintenance Préventive

• Hebdomadaire : Revue des builds échoués et patterns d'échec
• Mensuelle : Mise à jour des actions GitHub Actions
• Trimestrielle : Audit des permissions et accès
• Semestrielle : Revue et optimisation des workflows

11.3.2 Mise à Jour des Dépendances CI

• Node.js : Mise à jour vers nouvelle LTS annuellement
• Actions tierces : Mise à jour mensuelle (versions mineures)
• Terraform : Mise à jour trimestrielle
• Docker : Mise à jour des images de base mensuellement

12.1 Récapitulatif

Le pipeline CI/CD de REWAPP garantit :

• Qualité du code via tests automatisés et analyse statique
• Sécurité via scans continus des dépendances et images
• Fiabilité via déploiements Blue-Green et rollbacks automatiques
• Traçabilité via audit complet de tous les déploiements
• Rapidité via automatisation maximale du processus

12.2 Points Clés

12.3 Évolutions Prévues

Court terme (6 mois)

• Intégration de tests de performance K6 dans le pipeline
• Mise en place de feature flags pour déploiements progressifs
• Amélioration des tests E2E mobile avec Detox

Moyen terme (12 mois)

• Migration vers GitLab CI ou GitHub Actions Enterprise
• Pipeline de déploiement multi-région
• Intégration de chaos engineering (tests de résilience)

12.4 Documents Complémentaires

• 10.1 Plan de Déploiement
• 10.2 Documentation Technique Ops
• 10.3 Monitoring et Alerting
• 10.4 Sauvegarde et Disaster Recovery
• 8.1 Plan de Tests Global
• 6.1 Document de Sécurité