Låt AI skriva utkastet, men låt produktionsdatan bestämma planen. Separera schemaändring, datamigrering och applikationskod. Gör först den nya strukturen kompatibel med den gamla koden, flytta data i omstartbara omgångar, verifiera verkligt utfall och ta bort det gamla först när ingen längre använder det.
Kod kan rullas tillbaka. Data kräver en egen väg
En vanlig applikationsrelease går ofta att backa genom att driftsätta den förra versionen. En databasmigrering ändrar däremot ett tillstånd som båda versionerna delar. Har kolumnen tagits bort, värden skrivits över eller två fält slagits ihop kommer inte datan tillbaka bara för att den gamla koden gör det.
Det gör migrationskod annorlunda än annan genererad kod. Felet kan vara syntaktiskt korrekt, klara testsviten och ändå bli dyrt först när det möter produktionens volym, trafik och smutsiga historik. Modellen ser ditt schema och dina instruktioner. Den ser normalt inte hur många rader tabellen har, vilka ovanliga värden som faktiskt finns eller vilka äldre programversioner som fortfarande skriver till den.
Att migrationsverktyget kan köra en omvänd operation betyder inte att förlorad information kan återskapas. DROP COLUMN kan vändas genom att skapa kolumnen igen, men värdena är fortfarande borta. För destruktiva steg behövs en uttrycklig plan för bevarande eller återläsning av data — och den måste vara testad innan steget körs.
Börja med riskkartan, inte med SQL-koden
Den första prompten ska inte vara "skriv migrationen". Be i stället modellen hjälpa dig formulera vad du måste veta. En användbar riskkarta svarar på tre frågor som koden ensam sällan kan avgöra.
Resultatet är inte en migrationsfil utan ett beslutsunderlag: förväntad volym, kända avvikelser, berörda läsare och skrivare, verifieringsfrågor samt ett stoppvillkor. Först när det finns kan modellen hjälpa till att välja och skriva de tekniska stegen.
Be modellen visa vad den inte vet
Avsluta planeringsprompten med: "Lista antaganden som bara kan verifieras mot vår databas, driftsmiljö eller databasversion." Då hamnar osäkerheten i arbetslistan i stället för att döljas i en säker formulering.
Fyra steg: expandera, migrera, verifiera, dra ihop
Den säkraste vägen är ofta att låta gammalt och nytt fungera samtidigt under en period. Mönstret kallas ibland expand-and-contract. Namnet är mindre viktigt än ordningen: kompatibiliteten kommer före städningen.
Flera driftsättningar kan kännas långsammare än en enda migration. Men varje steg får en tydlig kontrollpunkt och en billigare väg tillbaka. Om den nya läsningen ger fel efter steg två kan du återgå till den gamla utan att först försöka återskapa en borttagen kolumn.
Håll isär tre ändringar som AI gärna blandar ihop
En prompt som beskriver slutläget lockar modellen att leverera allt på en gång. Då hamnar tre olika risker i samma diff och det blir svårt att avgöra vilket steg som orsakade ett fel.
Be modellen skriva en plan med en separat diff för varje kategori och ett testbart villkor mellan dem. Det följer samma princip som i Små diffar vinner: mindre ändringar är inte ett självändamål, utan ett sätt att göra varje antagande synligt och verifierbart.
Granska för det modellen inte kan se
En kodgranskning av migrationen behöver andra frågor än en vanlig funktionsändring. Syntax och stil är den enkla delen. Följande frågor avgör om migrationen går att driva säkert.
Guiden för kodgranskning frågar bland annat vad som händer vid fel och vilka behörigheter som krävs. Här ska de frågorna även ställas operativt: vilken användare kör migrationen, vilka tidsgränser gäller och vad lämnas kvar om processen avbryts mitt i?
Backfill är ett driftjobb, inte en engångsrad
På liten testdata ser UPDATE ... över hela tabellen rimligt ut. I produktion kan samma idé konkurrera med vanliga skrivningar, fylla loggar, belasta repliker eller pågå längre än deployfönstret. Exakt risk beror på miljön, men arbetsformen är densamma: gör jobbet styrbart.
Ett styrbart backfill-jobb har minst fem egenskaper
- Det arbetar i begränsade omgångar och kan pausas mellan dem.
- Det sparar eller kan härleda var det ska fortsätta efter ett avbrott.
- Det tål att redan behandlade rader möts igen.
- Det rapporterar antal behandlade, hoppade över och felaktiga rader.
- Det har ett förutbestämt stoppvillkor för felandel, svarstid eller annan belastning.
Be gärna AI om skelettet till jobbet och om testfall för avbrott och omkörning. Låt den däremot inte hitta på rimliga batchstorlekar eller belastningsgränser. De besluten ska komma från mätning i din miljö och från den som ansvarar för driften.
Prompten för en migrationsplan
En bra prompt börjar med nuläget och säkerhetskraven, inte med önskad SQL. Den ber först om en plan och håller osäkerheter öppna tills de har verifierats. Delarna är desamma som i Prompta för kod — uppgift, sammanhang, avgränsning och utfall — men sammanhanget här är driftmiljön och datan, inte bara koden.
Vi ska ändra [nuvarande schema och beteende] till [önskat slutläge].
Miljö: [databasmotor och version]. Produktionstabellen har ungefär [verifierat antal] rader. Under driftsättningen kan [gamla och nya appversioner] köra samtidigt.
Ta fram en plan i separata steg för expandera, migrera, verifiera och dra ihop. Blanda inte schema, backfill och applikationsändring i samma steg.
För varje steg: ange kompatibilitetskrav, verifieringsfråga, stoppvillkor och väg tillbaka. Markera destruktiva eller potentiellt låsande operationer.
Skriv ingen färdig migration ännu. Avsluta med antaganden som måste verifieras mot vår data, driftmiljö eller officiella dokumentation för databasversionen.
När planen är kontrollerad kan du be om kod för ett steg i taget. Ge modellen resultatet från den föregående verifieringen som ny kontext. Då bygger nästa utkast på vad som faktiskt hände, inte på vad den första planen antog skulle hända.
Innan du kör
En migration är redo när teamet kan svara konkret på följande, utan att hänvisa till att koden "ser rimlig ut":
AI gör det billigt att skriva migrationskod. Det gör inte själva migrationen billig att ha fel om. Den stora vinsten är därför inte att få en längre SQL-fil snabbare, utan att använda modellen till att bryta ned förändringen, synliggöra antaganden och skriva de små verktyg som låter dig mäta varje steg. Beslutet att köra — och risken när du gör det — stannar hos dig.