6 min lecture • Guide 508 of 877
Comment Gérer les Projets de Développement Microservices
Les architectures microservices nécessitent de coordonner plusieurs équipes travaillant sur des services indépendants avec des interdépendances complexes. Les fonctionnalités de dépendances cross-projets, suivi de contrats API et visibilité multi-équipes de GitScrum aident les organisations à gérer la complexité inhérente au développement de systèmes distribués.
Défis Projets Microservices
| Défi | Impact | Solution |
|---|---|---|
| Dépendances services | Travail bloqué | Mapping dépendances |
| Breaking changes API | Échecs intégration | Tests de contrat |
| Coordination déploiement | Pannes | Orchestration déploiement |
| Features cross-team | Overhead communication | Epics partagés |
| Propriété services | Responsabilité floue | Modèle propriété clair |
Organisation Projet
STRUCTURE PROJET MICROSERVICES
Option 1: Projet par Service
┌─────────────────────────────────────────────────┐
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌──────────┐ │
│ │Service User │ │Service Order│ │ Service │ │
│ │ Projet │ │ Projet │ │ Paiement │ │
│ │ │ │ │ │ Projet │ │
│ │ Équipe: Auth│ │Équipe:Orders│ │Équipe:Pay│ │
│ └─────────────┘ └─────────────┘ └──────────┘ │
│ │
│ Epic Cross-Projet: "Feature Checkout Mobile" │
│ └── Tâches distribuées à chaque projet service │
│ │
└─────────────────────────────────────────────────┘
Option 2: Projet par Domaine
┌─────────────────────────────────────────────────┐
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ Plateforme E-Commerce │ │
│ │ │ │
│ │ Swimlanes par Service: │ │
│ │ ├── Service User │ │
│ │ ├── Service Order │ │
│ │ ├── Service Paiement │ │
│ │ └── Service Notification │ │
│ │ │ │
│ │ Labels: [user-svc] [order-svc] [payment]│ │
│ └─────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────┘
Mapping des Dépendances
SUIVI DÉPENDANCES CROSS-SERVICES
FEATURE: Ajouter Checkout Express
┌─────────────────────────────────────────────────┐
│ Epic: Checkout Express │
│ │
│ Dépendances (séquence importante): │
│ │
│ Sprint N: │
│ └── [Design API] Contrat API Paiement │
│ └── [Design API] Contrat API Order │
│ │
│ Sprint N+1: │
│ ├── [Service User] Méthodes paiement sauvées │
│ └── [Service Paiement] Endpoint tokenisation │
│ └── Dépend de: Design API complet │
│ │
│ Sprint N+2: │
│ ├── [Service Order] Flow checkout express │
│ │ └── Dépend de: Tokenisation paiement │
│ └── [Frontend] UI Checkout │
│ └── Dépend de: API Service Order │
│ │
│ Sprint N+3: │
│ └── [Intégration] Tests end-to-end │
│ └── Dépend de: Tous services complets │
└─────────────────────────────────────────────────┘
Gestion Contrats API
WORKFLOW CONTRAT API
1. PHASE DESIGN
┌─────────────────────────────────────────────────┐
│ Tâche: Designer API Tokenisation Paiement │
│ │
│ Livrables: │
│ ☐ Spec OpenAPI dans dépôt partagé │
│ ☐ Revue avec équipes consommatrices │
│ ☐ Tests contrat définis │
│ ☐ Évaluation breaking change │
│ │
│ Reviewers: Équipes Service Order, Frontend │
└─────────────────────────────────────────────────┘
2. PHASE IMPLÉMENTATION
┌─────────────────────────────────────────────────┐
│ Tâche Producteur: Implémenter API Paiement │
│ ├── Implémenter endpoints selon spec │
│ ├── Exécuter tests contrat │
│ └── Déployer en staging │
│ │
│ Tâche Consommateur: Intégrer API Paiement │
│ ├── Bloqué jusqu'à: API en staging │
│ ├── Implémenter client │
│ └── Exécuter tests intégration │
└─────────────────────────────────────────────────┘
3. PROTOCOLE BREAKING CHANGE
┌─────────────────────────────────────────────────┐
│ Si breaking change nécessaire: │
│ │
│ Étape 1: Annoncer dans canal #api-changes │
│ Étape 2: Créer tâche migration pour consumers │
│ Étape 3: Versionner l'API (v1 → v2) │
│ Étape 4: Supporter deux versions pendant migration│
│ Étape 5: Déprécier ancienne version avec deadline│
│ Étape 6: Supprimer ancienne version après deadline│
└─────────────────────────────────────────────────┘
Coordination Déploiement
DÉPLOIEMENT MULTI-SERVICES
CHECKLIST DÉPLOIEMENT POUR FEATURE X:
┌─────────────────────────────────────────────────┐
│ │
│ Pré-Déploiement: │
│ ☐ Tous services passent les tests │
│ ☐ Tests contrat verts │
│ ☐ Migrations database prêtes │
│ ☐ Feature flags en place │
│ ☐ Procédures rollback documentées │
│ │
│ Ordre Déploiement (séquence requise): │
│ 1. ☐ Migrations database (tous services) │
│ 2. ☐ Service Paiement v2.3.0 │
│ 3. ☐ Service Order v1.8.0 │
│ 4. ☐ Service User v3.1.0 │
│ 5. ☐ Frontend v4.2.0 │
│ 6. ☐ Activer feature flag: express-checkout │
│ │
│ Post-Déploiement: │
│ ☐ Smoke tests passent │
│ ☐ Dashboards monitoring verts │
│ ☐ Taux erreur normaux │
│ ☐ Notifier stakeholders │
└─────────────────────────────────────────────────┘
Bonnes Pratiques
- Propriété service claire avec responsabilités documentées
- Design API-first avant implémentation
- Tests de contrat pour toutes interactions services
- Visibilité dépendances en gestion de projet
- Déploiement coordonné avec séquencement clair
- Feature flags pour features cross-services
- Monitoring partagé entre services
- Sync cross-team régulière pour travail dépendant
Anti-Patterns
✗ Services développés en isolation
✗ Breaking changes API sans préavis
✗ Pas de tests de contrat
✗ Propriété service floue
✗ Déploiement monolithique des microservices
✗ Pas de visibilité cross-team