Configurer des Workflows de Revue de Code Efficaces
Établissez des processus efficaces de revue de code en utilisant l'intégration de GitScrum avec GitHub, GitLab et Bitbucket incluant assignation automatisée des réviseurs, SLAs de revue, application de checklists, suivi de feedback et workflows d'approbation.
9 min de lecture
Les revues de code sont critiques pour maintenir la qualité, partager les connaissances et détecter les bugs avant la production. Mais des processus de revue mal conçus peuvent devenir des goulots d'étranglement qui frustrent les développeurs et ralentissent les livraisons. Les intégrations et fonctionnalités de workflow de GitScrum aident à établir des pratiques de revue qui sont approfondies mais efficaces.
Le Défi de la Revue de Code
Problèmes de revue courants:
| Problème | Impact |
|---|---|
| Revues trop longues | PRs s'accumulent, contexte perdu |
| Standards inconsistants | Qualité varie par réviseur |
| Attentes floues | Nitpicking vs. feedback important |
| Goulots réviseurs | Une personne bloque tous les PRs |
| Pas de responsabilité | Revues ignorées ou retardées |
Configuration Intégration GitScrum
Connexion Fournisseurs Git
Intégration Fournisseur Git:
PLATEFORMES SUPPORTÉES:
├── GitHub (Cloud & Enterprise)
├── GitLab (Cloud & Self-hosted)
└── Bitbucket (Cloud & Server)
ÉTAPES DE CONNEXION:
1. Settings → Integrations → Git Providers
2. Sélectionner fournisseur
3. Autoriser connexion OAuth
4. Choisir dépôts à connecter
5. Configurer paramètres synchronisation
OPTIONS SYNC:
┌─────────────────────────────────────────────────────────────┐
│ Configuration Intégration Git │
├─────────────────────────────────────────────────────────────┤
│ Dépôt: acme/frontend │
│ │
│ Paramètres Sync: │
│ ☑ Lier branches aux tâches (pattern: TASK-###) │
│ ☑ Lier PRs aux tâches │
│ ☑ Mettre à jour statut tâche sur événements PR │
│ ☑ Afficher statut PR dans détails tâche │
│ ☑ Importer commentaires PR comme commentaires tâche │
│ │
│ Mapping Statuts: │
│ PR Ouvert → Déplacer tâche vers: [En Revue ▼] │
│ PR Approuvé → Déplacer tâche vers: [Approuvé ▼] │
│ PR Fusionné → Déplacer tâche vers: [Fait ▼] │
│ PR Fermé → Déplacer tâche vers: [Pas de changement ▼]│
└─────────────────────────────────────────────────────────────┘
Liaison Automatique Tâches
Convention Nommage Branches:
PATTERN: [type]/TASK-[id]-[description]
Exemples:
├── feature/TASK-456-user-search
├── fix/TASK-789-login-bug
├── refactor/TASK-101-cleanup-auth
└── chore/TASK-202-update-deps
Flux Auto-Détection:
┌─────────────────────────────────────────────────────────────┐
│ 1. Développeur crée branche: │
│ git checkout -b feature/TASK-456-user-search │
│ │
│ 2. GitScrum détecte pattern "TASK-456" │
│ │
│ 3. Tâche TASK-456 auto-mise à jour: │
│ ├── Statut: → En Cours │
│ ├── Branche: feature/TASK-456-user-search │
│ └── Activité: "Branche créée par @alice" │
│ │
│ 4. Quand PR ouvert: │
│ ├── PR lié à tâche │
│ ├── Statut: → En Revue │
│ └── Activité: "PR #123 ouvert" │
│ │
│ 5. Quand PR fusionné: │
│ ├── Statut: → Fait │
│ └── Activité: "PR #123 fusionné vers main" │
└─────────────────────────────────────────────────────────────┘
Assignation Réviseurs
Règles Assignation Automatisée
Configuration Assignation Réviseurs:
STRATÉGIES ASSIGNATION:
┌─────────────────────────────────────────────────────────────┐
│ Règles Assignation Réviseurs │
├─────────────────────────────────────────────────────────────┤
│ │
│ Stratégie: [Round Robin ▼] │
│ │
│ Options: │
│ ├── Round Robin: Rotation entre membres équipe │
│ ├── Load Balanced: Assigner à personne avec moins revues │
│ ├── Code Ownership: Basé sur chemins fichiers modifiés │
│ ├── Aléatoire: Sélection random du pool │
│ └── Manuel: Auteur sélectionne, avec suggestions │
│ │
│ Pool Réviseurs: [Équipe Frontend ▼] │
│ ├── @alice (senior) │
│ ├── @bob (senior) │
│ ├── @carol (mid) │
│ └── @david (mid) │
│ │
│ Réviseurs Requis: [2] │
│ │
│ Règles: │
│ ☑ Au moins 1 réviseur senior │
│ ☑ Ne peut réviser ses propres PRs │
│ ☑ Exclure en congé (sync depuis calendrier) │
│ □ Requérir réviseur spécifique pour [security/*] │
└─────────────────────────────────────────────────────────────┘
Mapping Ownership Code
Assignation style CODEOWNERS:
Règles Chemin Fichier:
┌─────────────────────────────────────────────────────────────┐
│ Configuration Ownership Code │
├─────────────────────────────────────────────────────────────┤
│ │
│ Pattern Chemin Owners Requis │
│ ───────────────────────────────────────────────────────────│
│ /src/api/* @api-team 1 │
│ /src/components/ui/* @ui-team 1 │
│ /src/auth/* @security-team 2 │
│ /src/payments/* @payments-lead 1 + @security │
│ /database/* @dba-team 1 │
│ *.sql @dba-team 1 │
│ /tests/* @qa-lead Optionnel │
│ * @default-reviewers 1 │
│ │
│ Priorité: Première correspondance gagne (haut vers bas) │
└─────────────────────────────────────────────────────────────┘
Équilibrage Charge Revues
Assignation Équilibrée par Charge:
CHARGE REVUE ACTUELLE:
┌─────────────────────────────────────────────────────────────┐
│ CHARGE TRAVAIL RÉVISEURS [Cette Semaine] │
├─────────────────────────────────────────────────────────────┤
│ │
│ Revues Actives: │
│ Alice: [██░░░░░░] 2 PRs (capacité: 4) ← Proch assign │
│ Bob: [████░░░░] 4 PRs (capacité: 4) Plein │
│ Carol: [███░░░░░] 3 PRs (capacité: 4) │
│ David: [██░░░░░░] 2 PRs (capacité: 4) ← Proch assign │
│ │
│ Stats Revue Cette Semaine: │
│ ├── Alice: 8 complétées, moy 4h réponse │
│ ├── Bob: 6 complétées, moy 6h réponse │
│ ├── Carol: 7 complétées, moy 3h réponse │
│ └── David: 5 complétées, moy 8h réponse │
└─────────────────────────────────────────────────────────────┘
SLAs Revue et Suivi
Attentes Basées sur Temps
Configuration SLA Revue:
┌─────────────────────────────────────────────────────────────┐
│ SLAs Revue Code │
├─────────────────────────────────────────────────────────────┤
│ │
│ SLA Première Réponse: │
│ ├── P0/Critique: 2 heures │
│ ├── P1/Haute: 4 heures │
│ ├── P2/Normal: 8 heures (1 jour ouvré) │
│ └── P3/Basse: 24 heures │
│ │
│ SLA Complétion Revue: │
│ ├── Petit PR (<100 lignes): 4h après première réponse │
│ ├── PR Moyen (100-500 lignes): 8 heures │
│ └── Grand PR (>500 lignes): 24 heures │
│ │
│ Règles Escalade: │
│ ├── 50% du SLA: Rappel au réviseur │
│ ├── 100% du SLA: Notifier team lead │
│ ├── 150% du SLA: Escalader à eng manager │
│ └── 200% du SLA: Permettre merge sans revue complète │
└─────────────────────────────────────────────────────────────┘
Dashboard Statut Revue
Dashboard Pipeline Revue:
┌─────────────────────────────────────────────────────────────┐
│ PIPELINE REVUE CODE [Derniers 7 Jours ▼]│
├─────────────────────────────────────────────────────────────┤
│ │
│ Statut Actuel: │
│ ├── En Attente Revue: 8 PRs │
│ ├── En Revue: 5 PRs │
│ ├── Changements Demandés: 3 PRs │
│ └── Approuvés (merge en attente): 2 PRs │
│ │
│ Performance SLA: │
│ │ Première Réponse │
│ │ À Temps: ████████████████████ 85% │
│ │ Retard: ████ 15% │
│ │ │
│ │ Complétion Revue │
│ │ À Temps: ██████████████████ 78% │
│ │ Retard: ██████ 22% │
│ │
│ PRs Risque SLA: │
│ ├── 🔴 PR #456: 6h retard (assigné: @bob) │
│ ├── 🟡 PR #461: 2h restantes (assigné: @carol) │
│ └── 🟡 PR #463: 3h restantes (assigné: @alice) │
└─────────────────────────────────────────────────────────────┘
Checklists Revue
Critères Revue Standardisés
Template Checklist Revue Code:
┌─────────────────────────────────────────────────────────────┐
│ CHECKLIST REVUE PR │
├─────────────────────────────────────────────────────────────┤
│ │
│ FONCTIONNALITÉ │
│ □ Code fait ce que la description tâche dit │
│ □ Cas edge sont gérés │
│ □ Gestion erreurs est appropriée │
│ □ Pas de bugs évidents │
│ │
│ QUALITÉ CODE │
│ □ Code est lisible et auto-documenté │
│ □ Fonctions/méthodes ont taille appropriée │
│ □ Pas de duplication code │
│ □ Suit conventions et patterns du projet │
│ │
│ TESTING │
│ □ Tests unitaires couvrent nouvelle fonctionnalité │
│ □ Tests sont significatifs (pas juste couverture) │
│ □ Cas edge sont testés │
│ □ Tests passent local et en CI │
│ │
│ SÉCURITÉ │
│ □ Pas de données sensibles exposées │
│ □ Validation input en place │
│ □ Authentification/autorisation correcte │
│ □ Pas de vulnérabilités SQL injection ou XSS │
│ │
│ PERFORMANCE │
│ □ Pas de problèmes performance évidents │
│ □ Requêtes DB sont efficaces (pas N+1) │
│ □ Caching approprié considéré │
└─────────────────────────────────────────────────────────────┘
Qualité Feedback
Catégories Commentaires
Types Feedback Structuré:
PRÉFIXES COMMENTAIRE:
┌─────────────────────────────────────────────────────────────┐
│ Préfixe Signification Bloquant? │
├─────────────────────────────────────────────────────────────┤
│ [BLOCKER] Doit corriger avant merge Oui │
│ [ISSUE] Devrait corriger, important Oui (souvent) │
│ [SUGGEST] Considérer changer Non │
│ [NIT] Mineur/préférence style Non │
│ [QUESTION] Besoin clarification Dépend │
│ [PRAISE] Bon travail, bon code Non │
│ [FYI] Partage information Non │
└─────────────────────────────────────────────────────────────┘
Exemples:
[BLOCKER] Cette requête SQL est vulnérable à l'injection.
Veuillez utiliser des requêtes paramétrées.
[ISSUE] Cette fonction fait 200 lignes. Considérez diviser
en fonctions plus petites pour testabilité.
[SUGGEST] Vous pourriez simplifier ceci avec un reduce()
[NIT] Je préférerais `isActive` plutôt que `active` pour noms boolean.
[PRAISE] Implémentation très propre de la couche cache!
Workflows Approbation
Approbations Multi-Étapes
Exigences Approbation:
PR STANDARD:
┌─────────────────────────────────────────────────────────────┐
│ Exigences pour Merge: │
│ ├── 1+ approbation de l'équipe │
│ ├── Tous blockers résolus │
│ ├── Checks CI passent │
│ └── Pas de threads non résolus │
└─────────────────────────────────────────────────────────────┘
ZONES SENSIBLES:
┌─────────────────────────────────────────────────────────────┐
│ Chemin: /src/auth/*, /src/payments/* │
│ Exigences: │
│ ├── 2+ approbations │
│ ├── 1 doit être de l'équipe sécurité │
│ ├── Toutes checklists complètes │
│ └── CI étendu (scans sécurité) │
└─────────────────────────────────────────────────────────────┘