Skip to main content

50 Dateien von REST auf GraphQL migrieren

Planen Sie eine REST-zu-GraphQL-Migration für 50 Dateien, teilen Sie diese in konfliktfreie Arbeitspakete auf und führen Sie sie alle gleichzeitig in Batch-Sitzungen aus.
AuthorCognition
CategoryMigrations
FeaturesAdvanced, Playbooks
1

Legen Sie den Umfang der Migration mit Ask Devin fest

Du hast 50 Dateien, die aus src/lib/restClient.ts importieren und auf den neuen graphqlClient umgestellt werden müssen. Bevor du irgendetwas in parallele Arbeitspakete aufteilst, musst du verstehen, wie diese Dateien miteinander verbunden sind. Verwende Ask Devin, um den Migrationsumfang zu kartieren — welche Dateien den Legacy-Client importieren, wie sie sich nach Domänen gruppieren und wo riskante Kopplungen liegen. Devin verwendet unter der Haube DeepWiki und semantische Suche, sodass es diese Fragen fundiert auf Grundlage deines tatsächlichen Codes beantworten kann.
Ask Devin setzt voraus, dass dein Repository indiziert ist. Gehe zu Settings > Repositories, um den Indizierungsstatus zu prüfen oder ein neues Repo zu indizieren.
Öffne Ask Devin und frage:Ask Devin liefert eine Aufschlüsselung in etwa wie diese:
50 Dateien importieren restClient in 8 Domänen:

  User Management  (7 Dateien) — isoliert, vollständige Testabdeckung
  Billing          (9 Dateien) — isoliert, 6/9 getestet
  Analytics        (5 Dateien) — isoliert, 3/5 getestet
  Auth             (6 Dateien) — gemeinsame Middleware, vollständige Testabdeckung
  Notifications    (8 Dateien) — isoliert, 5/8 getestet
  Admin            (5 Dateien) — abhängig von Auth-Middleware
  Search           (4 Dateien) — isoliert, 2/4 getestet
  Onboarding       (6 Dateien) — isoliert, 4/6 getestet

Kopplungshinweis: Admin importiert requireAuth aus Auth. Zuerst
Auth migrieren, dann Admin. Alle anderen Domänen sind unabhängig.
Dies zeigt Ihnen, ob Parallelisierung sinnvoll ist. Wenn die meisten Dateien stark über Domains hinweg gekoppelt sind, ist eine sequentielle Migration sicherer. Hier sind 6 von 8 Domains vollständig unabhängig – Sie können sie parallel migrieren.
2

Erstellen Sie ein Migrations-Playbook

Jede parallele Sitzung sollte demselben Migrationsmuster folgen, damit die resultierenden PRs konsistent und leicht zu überprüfen sind. Erstelle ein Playbook, das genau definiert, wie jede Datei migriert werden soll.Gehe zu Settings > Playbooks > Create Playbook und definiere die Schritte:Oder verwende Advanced Devin, um das Playbook für dich zu erstellen – beschreibe dein Migrationsmuster, und es erzeugt ein vollständiges Playbook:Wenn du in deinem Orchestrierungs-Prompt auf dieses Playbook verweist, stellst du sicher, dass alle parallelen Sitzungen PRs erzeugen, die so aussehen, als wären sie vom selben Entwickler erstellt worden.
3

Starte parallele Sitzungen mit Advanced Devin

Öffne Advanced Devin (das Funkel-Icon in der Web-App) und gib ihm den Orchestrierungs-Prompt. Advanced Devin analysiert den Abhängigkeitsgraphen deiner Codebasis, erstellt unabhängige Arbeitspakete und startet eine Batch-Session pro Paket – alle laufen gleichzeitig.Advanced Devin zeigt dir eine Gruppierung zur Genehmigung an, bevor etwas gestartet wird:
Proposed work packages (8 groups, 50 files total):

Group 1 — User Management (7 files, complexity: 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

Group 2 — Billing (9 files, complexity: 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

Group 3 — Analytics (5 files, complexity: S)
  src/services/AnalyticsService.ts, src/pages/Dashboard.tsx,
  src/components/MetricsCard.tsx, src/hooks/useMetrics.ts,
  src/components/ChartPanel.tsx

Group 4 — Auth (6 files, complexity: L) ⚠ migrate first
  src/services/AuthService.ts, src/middleware/requireAuth.ts,
  src/middleware/refreshToken.ts, src/pages/Login.tsx,
  src/pages/Signup.tsx, src/services/SessionService.ts

Group 5 — Notifications (8 files, complexity: 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

Group 6 — Admin (5 files, complexity: M) ⚠ depends on Auth
  src/pages/AdminDashboard.tsx, src/pages/AdminUsers.tsx,
  src/services/AdminService.ts, src/components/AdminSidebar.tsx,
  src/middleware/requireAdmin.ts

Group 7 — Search (4 files, complexity: S)
  src/services/SearchService.ts, src/pages/SearchResults.tsx,
  src/components/SearchBar.tsx, src/hooks/useSearch.ts

Group 8 — Onboarding (6 files, complexity: 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

Dependency note: Group 6 (Admin) imports middleware from Group 4
(Auth). Will launch Auth first, then Admin after Auth's PR merges.
Launch remaining 6 groups in parallel immediately.

Start 6 parallel sessions now + 2 sequential? (y/n)
Genehmige die Gruppierung und starte alle sechs Sessions auf einmal. Auth läuft zuerst, anschließend folgt Admin, sobald Auth gemergt ist.
4

Ergebnisse überprüfen und zusammenführen

Jede Session erstellt ihren eigenen Pull Request (PR). Da die Pakete unabhängig sind, kannst du sie in beliebiger Reihenfolge prüfen und mergen — merge aber zuerst Auth, da Admin davon abhängt, und führe nach jedem Merge einen vollständigen CI-Lauf aus, um unerwartete Interaktionen zu erkennen.Sobald alle 8 Migrations-PRs gemergt sind, nutze eine anschließende Session, um toten Code aufzuräumen: