Skip to main content

Migrer 50 fichiers de REST vers GraphQL

Délimitez le périmètre d'une migration REST-vers-GraphQL portant sur 50 fichiers, divisez-la en lots de travail sans conflits et exécutez-les tous en parallèle grâce aux sessions par lots.
AuthorCognition
CategoryMigrations
FeaturesAvancé, Playbooks
1

Définir le périmètre de la migration avec Ask Devin

Vous avez 50 fichiers qui importent depuis src/lib/restClient.ts et devez migrer vers le nouveau graphqlClient. Avant de répartir le travail en parallèle, vous devez comprendre comment ces fichiers sont reliés. Utilisez Ask Devin pour cartographier le périmètre de la migration : quels fichiers importent l’ancien client, comment ils se regroupent par domaine et où se trouvent les couplages risqués. Devin utilise DeepWiki et la recherche sémantique en arrière-plan, ce qui lui permet de répondre à ces questions en s’appuyant sur votre code existant.
Ask Devin nécessite que votre dépôt soit indexé. Allez dans Settings > Repositories pour vérifier l’état d’indexation ou indexer un nouveau dépôt.
Ouvrez Ask Devin et demandez :Ask Devin renvoie une analyse comme celle-ci :
50 fichiers importent restClient dans 8 domaines :

  User Management  (7 fichiers) — isolé, couverture de tests complète
  Billing          (9 fichiers) — isolé, 6/9 testés
  Analytics        (5 fichiers) — isolé, 3/5 testés
  Auth             (6 fichiers) — middleware partagé, couverture de tests complète
  Notifications    (8 fichiers) — isolé, 5/8 testés
  Admin            (5 fichiers) — dépend du middleware Auth
  Search           (4 fichiers) — isolé, 2/4 testés
  Onboarding       (6 fichiers) — isolé, 4/6 testés

Remarque sur le couplage : Admin importe requireAuth depuis Auth. Migrer
Auth en premier, puis Admin. Tous les autres domaines sont indépendants.
Cela vous indique si la parallélisation est pertinente. Si la plupart des fichiers sont fortement couplés entre domaines, une migration séquentielle est plus sûre. Ici, 6 domaines sur 8 sont totalement indépendants — vous pouvez les traiter en parallèle.
2

Créer un playbook de migration

Chaque session parallèle doit suivre le même modèle de migration afin que les PR soient cohérentes et faciles à examiner. Créez un playbook qui définit exactement comment chaque fichier doit être migré.Allez dans Settings > Playbooks > Create Playbook et définissez les étapes :Ou utilisez Advanced Devin pour générer le playbook pour vous : décrivez votre modèle de migration et il produira un playbook complet :Le fait de référencer ce playbook dans votre prompt d’orchestration garantit que toutes les sessions parallèles produisent des PR qui semblent provenir du même développeur.
3

Lancez des sessions en parallèle avec Advanced Devin

Ouvrez Advanced Devin (l’icône en forme d’étincelle dans l’application web) et donnez-lui la consigne d’orchestration. Advanced Devin analyse le graphe de dépendances de votre base de code, crée des ensembles de travail indépendants et lance une session par ensemble — toutes s’exécutant en parallèle.Advanced Devin vous présente un regroupement pour validation avant de lancer quoi que ce soit :
Packages de travail proposés (8 groupes, 50 fichiers au total) :

Groupe 1 — User Management (7 fichiers, complexité : M)
  src/services/UserService.ts, src/pages/Profile.tsx,
  src/pages/Settings.tsx, src/hooks/useCurrentUser.ts,
  src/pages/UserDirectory.tsx, src/services/AvatarService.ts,
  src/components/UserCard.tsx

Groupe 2 — Billing (9 fichiers, complexité : L)
  src/services/BillingService.ts, src/services/InvoiceService.ts,
  src/services/SubscriptionService.ts, src/pages/Checkout.tsx,
  src/pages/PlanSelector.tsx, src/pages/InvoiceHistory.tsx,
  src/components/PaymentForm.tsx, src/hooks/useSubscription.ts,
  src/components/PricingTable.tsx

Groupe 3 — Analytics (5 fichiers, complexité : S)
  src/services/AnalyticsService.ts, src/pages/Dashboard.tsx,
  src/components/MetricsCard.tsx, src/hooks/useMetrics.ts,
  src/components/ChartPanel.tsx

Groupe 4 — Auth (6 fichiers, complexité : L) ⚠ migrer en premier
  src/services/AuthService.ts, src/middleware/requireAuth.ts,
  src/middleware/refreshToken.ts, src/pages/Login.tsx,
  src/pages/Signup.tsx, src/services/SessionService.ts

Groupe 5 — Notifications (8 fichiers, complexité : M)
  src/services/NotificationService.ts, src/services/EmailService.ts,
  src/services/PushService.ts, src/pages/NotificationPreferences.tsx,
  src/components/NotificationBell.tsx, src/hooks/useNotifications.ts,
  src/components/NotificationToast.tsx, src/services/WebhookService.ts

Groupe 6 — Admin (5 fichiers, complexité : M) ⚠ dépend de Auth
  src/pages/AdminDashboard.tsx, src/pages/AdminUsers.tsx,
  src/services/AdminService.ts, src/components/AdminSidebar.tsx,
  src/middleware/requireAdmin.ts

Groupe 7 — Search (4 fichiers, complexité : S)
  src/services/SearchService.ts, src/pages/SearchResults.tsx,
  src/components/SearchBar.tsx, src/hooks/useSearch.ts

Groupe 8 — Onboarding (6 fichiers, complexité : M)
  src/services/OnboardingService.ts, src/pages/Welcome.tsx,
  src/pages/SetupWizard.tsx, src/components/ProgressTracker.tsx,
  src/hooks/useOnboardingState.ts, src/services/ChecklistService.ts

Note de dépendance : le Groupe 6 (Admin) importe des middlewares du Groupe 4
(Auth). Auth sera lancé en premier, puis Admin après la fusion de la PR d'Auth.
Lancement des 6 groupes restants en parallèle immédiatement.

Démarrer 6 sessions parallèles maintenant + 2 séquentielles ? (o/n)
Approuvez le regroupement et le lancement simultané des six sessions. Auth s’exécute en premier, puis Admin démarre une fois Auth fusionné.
4

Examiner et fusionner les résultats

Chaque session ouvre sa propre PR. Étant donné que les packages sont indépendants, vous pouvez les examiner et les fusionner dans n’importe quel ordre — mais fusionnez Auth en premier, car Admin en dépend, et exécutez la CI complète après chaque fusion pour détecter toute interaction inattendue.Une fois les 8 PR de migration fusionnées, utilisez une session de suivi pour nettoyer le code mort :