4 min lecture • Guide 537 of 877
Gestion de Projet Microservices
Les architectures microservices distribuent la complexité à travers de multiples services appartenant à différentes équipes. L'organisation multi-projets de GitScrum, le suivi des dépendances de service et les fonctionnalités de visibilité inter-équipes aident les organisations à maintenir contrôle et coordination à travers le développement de microservices distribués.
Modèles d'Organisation Microservices
| Modèle | Idéal Pour | Compromis |
|---|---|---|
| Projet par service | Beaucoup de services, équipes claires | Plus de projets à gérer |
| Projet par domaine | Groupements logiques | Peut traverser plusieurs équipes |
| Projet partagé + labels | Peu de services, petite org | Moins d'isolation |
| Hybride | Organisations complexes | Flexibilité vs complexité |
Organisation de Projet
OPTIONS D'ORGANISATION
OPTION 1: PROJET PAR SERVICE
┌─────────────────────────────────────────────────┐
│ Workspace GitScrum │
│ ├── Projet: user-service │
│ │ └── Owner: Équipe Auth │
│ ├── Projet: order-service │
│ │ └── Owner: Équipe Commandes │
│ ├── Projet: payment-service │
│ │ └── Owner: Équipe Paiements │
│ ├── Projet: inventory-service │
│ │ └── Owner: Équipe Inventaire │
│ └── Projet: notification-service │
│ └── Owner: Équipe Plateforme │
│ │
│ Pros: Ownership clair, backlogs isolés │
│ Cons: Beaucoup projets, overhead cross-projet │
└─────────────────────────────────────────────────┘
OPTION 2: PROJET PAR DOMAINE
┌─────────────────────────────────────────────────┐
│ Workspace GitScrum │
│ ├── Projet: Domaine Client │
│ │ ├── user-service │
│ │ └── profile-service │
│ ├── Projet: Domaine Commerce │
│ │ ├── order-service │
│ │ ├── payment-service │
│ │ └── cart-service │
│ └── Projet: Domaine Opérations │
│ ├── inventory-service │
│ ├── shipping-service │
│ └── notification-service │
│ │
│ Pros: Groupement logique, moins de projets │
│ Cons: Peut traverser frontières équipes │
└─────────────────────────────────────────────────┘
OPTION 3: PROJET PARTAGÉ AVEC LABELS
┌─────────────────────────────────────────────────┐
│ Workspace GitScrum │
│ └── Projet: Développement Plateforme │
│ Labels: │
│ ├── [svc:user] │
│ ├── [svc:order] │
│ ├── [svc:payment] │
│ ├── [svc:inventory] │
│ └── [svc:notification] │
│ │
│ Vues filtrées par service │
│ │
│ Pros: Simple, vue unifiée │
│ Cons: Moins d'isolation, besoin discipline │
└─────────────────────────────────────────────────┘
Suivi Features Cross-Services
STRUCTURE EPIC CROSS-SERVICES
Epic: Fonctionnalité Checkout Express
├── Statut: En Développement
├── Cible: Sprint 8
├── Owner: @product-manager
│
├── Tâches par Service:
│
├── [user-service] Moyens de paiement sauvegardés
│ ├── Stocker tokens paiement chiffrés
│ ├── API ajout moyen de paiement
│ └── API liste moyens de paiement
│
├── [order-service] Création commande rapide
│ ├── Endpoint checkout express
│ ├── Appliquer moyen paiement sauvegardé
│ └── Confirmation commande
│
├── [payment-service] Traitement tokens
│ ├── Valider token paiement
│ ├── Traiter paiement tokenisé
│ └── Gestion webhooks
│
└── [notification-service] Alertes commande
├── Email confirmation commande express
└── Notification push mobile
Dépendances:
├── payment-service → user-service (tokens)
├── order-service → payment-service (traitement)
└── frontend → toutes APIs terminées