GitHub CI/CD Pipeline - MaaS Platform

Ce dossier contient l'ensemble de la configuration CI/CD pour la plateforme MaaS, incluant les workflows GitHub Actions, les templates d'issues et de pull requests, et les configurations de dépendances.

Structure

.github/
├── workflows/              # GitHub Actions workflows
│   ├── ci.yml             # Intégration continue
│   ├── docker-build.yml   # Build et push des images Docker
│   ├── deploy-dev.yml     # Déploiement en développement
│   ├── deploy-staging.yml # Déploiement en staging
│   ├── deploy-prod.yml    # Déploiement en production
│   ├── security-scan.yml  # Scans de sécurité quotidiens
│   └── quality-checks.yml # Vérifications qualité sur PRs
├── issue_template/         # Templates d'issues
│   ├── bug_report.md
│   ├── feature_request.md
│   ├── performance_issue.md
│   ├── security_issue.md
│   └── config.yml
├── dependabot.yml         # Configuration Dependabot
├── CODEOWNERS            # Propriétaires de code
└── pull_request_template.md  # Template de PR

Workflows

1. CI Pipeline (ci.yml)

Déclenchement: Push/PR sur main et develop

Jobs:

• Code quality & formatting
• Build & test (matrice par service)
• Tests d'intégration
• Code coverage (seuil minimum: 80%)
• SonarQube analysis
• Dependency scanning (Snyk, Trivy)
• SAST (CodeQL)
• Secret scanning (TruffleHog)

Durée estimée: 15-25 minutes

2. Docker Build (docker-build.yml)

Déclenchement: Push sur main, tags v*.*.*, PRs

Jobs:

• Build multi-platform (amd64, arm64)
• Scan de sécurité (Trivy, Grype)
• Push vers GitHub Container Registry
• Génération SBOM
• Nettoyage des anciennes images

Durée estimée: 10-20 minutes

3. Deploy Dev (deploy-dev.yml)

Déclenchement: Push sur main

Jobs:

• Validation des manifestes Kubernetes
• Déploiement sur cluster dev
• Migrations de base de données
• Health checks
• Smoke tests

Durée estimée: 10-15 minutes

4. Deploy Staging (deploy-staging.yml)

Déclenchement: Tags v*.*.*-rc*, v*.*.*-beta*, manuel

Jobs:

• Validation pré-déploiement
• Approbation manuelle requise
• Déploiement sur staging
• Tests d'intégration
• Tests de performance (k6)
• Tests E2E (Playwright)

Durée estimée: 30-45 minutes

5. Deploy Production (deploy-prod.yml)

Déclenchement: Release publiée, manuel

Stratégies de déploiement:

• Blue-Green (par défaut)
• Canary (10% → 50% → 100%)
• Rolling

Jobs:

• Vérifications pré-production
• Approbation manuelle obligatoire
• Backup de la base de données
• Déploiement avec stratégie choisie
• Monitoring et validation
• Rollback automatique en cas d'échec

Durée estimée: 20-40 minutes

6. Security Scan (security-scan.yml)

Déclenchement: Quotidien (2h UTC), manuel, changements de dépendances

Jobs:

• Dependency scanning (Snyk, Trivy, OWASP)
• Container scanning (tous les services)
• Secret scanning (TruffleHog, Gitleaks)
• SAST (CodeQL, SecurityCodeScan)
• IaC scanning (Trivy, Checkov)
• DAST (OWASP ZAP)
• License compliance

Durée estimée: 25-35 minutes

7. Quality Checks (quality-checks.yml)

Déclenchement: PRs

Jobs:

• Code quality analysis
• Test coverage (minimum 80%)
• Security vulnerability check
• Code style & formatting
• Documentation check
• Breaking change detection
• PR size check
• Quality gate summary

Durée estimée: 10-15 minutes

Configuration des Secrets

Les secrets suivants doivent être configurés dans GitHub Settings > Secrets and variables > Actions:

Kubernetes

KUBECONFIG_DEV      # Base64 encoded kubeconfig for dev
KUBECONFIG_STAGING  # Base64 encoded kubeconfig for staging
KUBECONFIG_PROD     # Base64 encoded kubeconfig for production

Database

DB_PASSWORD_DEV
DB_PASSWORD_STAGING
DB_PASSWORD_PROD

Redis

REDIS_PASSWORD_DEV
REDIS_PASSWORD_STAGING
REDIS_PASSWORD_PROD

RabbitMQ

RABBITMQ_PASSWORD_DEV
RABBITMQ_PASSWORD_STAGING
RABBITMQ_PASSWORD_PROD

Security & Authentication

JWT_SECRET_DEV
JWT_SECRET_STAGING
JWT_SECRET_PROD
STRIPE_API_KEY_STAGING
STRIPE_API_KEY_PROD

Security Scanning

SONAR_TOKEN          # SonarQube token
SONAR_HOST_URL       # SonarQube server URL
SNYK_TOKEN           # Snyk API token
CODECOV_TOKEN        # Codecov upload token
FOSSA_API_KEY        # FOSSA license scanning (optional)
GITLEAKS_LICENSE     # Gitleaks Pro license (optional)

Notifications

SLACK_WEBHOOK_URL    # Slack webhook for notifications

Testing

TEST_USER_EMAIL      # Test user for staging tests
TEST_USER_PASSWORD   # Test user password

Environments GitHub

Créer les environments suivants dans GitHub Settings > Environments:

development

• Auto-deployment: Enabled
• Protection rules: None

staging-approval

• Required reviewers: Platform team lead
• Wait timer: 0 minutes

staging

• Required reviewers: None
• Deployment branches: Tags matching v*.*.*-rc*, v*.*.*-beta*

production-approval

• Required reviewers: 2 members from platform-team
• Wait timer: 5 minutes

production

• Required reviewers: None
• Deployment branches: Tags matching v*.*.* (releases only)

Dependabot Configuration

Dependabot est configuré pour:

• Updates hebdomadaires des packages NuGet
• Updates des images Docker
• Updates des GitHub Actions
• Groupement des dépendances Microsoft
• Pull requests limitées par service

Configuration dans /home/user/trip/.github/dependabot.yml

CODEOWNERS

Le fichier CODEOWNERS définit les équipes responsables de chaque partie du code:

• @platform-team - Propriétaires globaux
• @devops-team - CI/CD et infrastructure
• @security-team - Code sensible à la sécurité
• @qa-team - Tests
• Service teams - Chaque microservice

Templates

Pull Request Template

Template complet incluant:

• Description et type de changement
• Testing et coverage
• Security checklist
• Documentation requirements
• Deployment notes
• Breaking changes

Issue Templates

1. Bug Report - Rapport de bug détaillé
2. Feature Request - Demande de fonctionnalité
3. Performance Issue - Problème de performance
4. Security Issue - Problème de sécurité non critique

Badges de Statut

Ajouter ces badges dans votre README principal:

![CI](https://github.com/your-org/maas-platform/workflows/Continuous%20Integration/badge.svg)
![Security](https://github.com/your-org/maas-platform/workflows/Security%20Scanning/badge.svg)
[![codecov](https://codecov.io/gh/your-org/maas-platform/branch/main/graph/badge.svg)](https://codecov.io/gh/your-org/maas-platform)

Workflow de Développement

Feature Development

1. Créer une branche depuis develop
2. Développer la fonctionnalité
3. Push → CI pipeline s'exécute
4. Créer une PR → Quality checks s'exécutent
5. Review et merge → CI sur develop

Release Process

1. Merge develop → main
2. Docker images sont buildées automatiquement
3. Déploiement automatique en dev
4. Tag avec version (e.g., v1.2.3-rc1)
5. Déploiement en staging (après approbation)
6. Tests complets sur staging
7. Créer une release GitHub (e.g., v1.2.3)
8. Déploiement en production (après approbation)

Hotfix Process

1. Créer une branche hotfix/ depuis main
2. Fix le problème
3. Tag avec patch version (e.g., v1.2.4)
4. Déploiement direct en production
5. Merge back vers develop

Monitoring et Notifications

Slack Notifications

Les notifications sont envoyées sur Slack pour:

• Déploiements (dev, staging, production)
• Échecs de build
• Scans de sécurité quotidiens
• Rollbacks

GitHub Checks

Tous les workflows créent des checks sur les PRs:

• ✅ CI Pipeline
• ✅ Quality Checks
• ✅ Security Scan
• ✅ Docker Build

Best Practices

1. Always run tests locally avant de push
2. Keep PRs small - Maximum 500 lignes de changement
3. Write meaningful commit messages - Conventional commits
4. Update tests avec chaque changement de code
5. Review security scan results régulièrement
6. Keep dependencies updated - Review Dependabot PRs
7. Monitor coverage - Maintenir >80%
8. Document breaking changes dans CHANGELOG

Troubleshooting

Workflow Failed

1. Vérifier les logs dans l'onglet Actions
2. Rechercher les messages d'erreur
3. Vérifier les secrets/variables d'environnement
4. Re-run le workflow si erreur temporaire

Coverage Below Threshold

1. Ajouter des tests unitaires
2. Améliorer la couverture des branches
3. Vérifier les fichiers exclus

Security Scan Issues

1. Review les vulnérabilités dans Security tab
2. Mettre à jour les dépendances
3. Appliquer les patches de sécurité
4. Re-scanner après corrections

Deployment Failed

1. Vérifier les logs Kubernetes
2. Vérifier la santé des pods
3. Rollback si nécessaire
4. Investiguer et corriger

Support

Pour toute question ou problème:

• Créer une issue avec le template approprié
• Contacter l'équipe DevOps
• Consulter la documentation: https://docs.maas.example.com

Maintenance

Mise à jour des Workflows

Les workflows doivent être revus et mis à jour:

• Mensuellement pour les optimisations
• Lors de changements d'architecture
• Lors de nouveaux services
• Pour les nouvelles versions d'actions

Audit de Sécurité

Un audit complet doit être effectué:

• Trimestriellement
• Après incidents de sécurité
• Avant certifications (SOC2, ISO27001)

---

Dernière mise à jour: 2025-11-16 Version: 1.0.0 Mainteneur: Platform Team