A Google Antigravity CLI-val automatizálta a Spanner-migráció dual-write lépéseit

A migráció során párhuzamos írásra volt szükség

A Google Finance Engineering csapata egy régi adatréteg korszerűsítéséhez választotta a Spannert. A Google leírása szerint a Spanner globálisan elosztott, erősen konzisztens, többmodelles adatbázis, amely magas rendelkezésre állást kínál. Az átállás egyik fő nehézsége az volt, hogy a termelési szolgáltatásokat leállítás nélkül kellett migrálni.

Ehhez a régi adattárnak és a Cloud Spannernek egyidejűleg azonos írásokat kellett fogadnia mindaddig, amíg a korábbi adatok feltöltése és az ellenőrzések be nem fejeződtek. A csapat három szakaszt határozott meg: a történeti adatok feltöltését, a párhuzamos írás és olvasás bevezetését, valamint az API-k automatizált ellenőrzését és az adategyezés vizsgálatát.

Az utóbbi folyamat az RPC-forgalmat is ellenőrizte, és azt vizsgálta, hogy minden írás bájtról bájtra azonos módon jelenik-e meg a két adattárban. A megoldást több mint 30 adatelérési objektumon, vagyis DAO-n kellett alkalmazni.

Egységes MutationConverter-mintát alakítottak ki

Minden DAO esetében külön MutationConverter osztályra volt szükség, amely a komplex üzleti modelleket a Spanner oszlopaira képezi le. Emellett a párhuzamos írás ágát, a visszagörgetés vagy hibajelzés logikáját, valamint a régi és az új adattárba történő írásokat ellenőrző egységteszteket is létre kellett hozni.

A Google szerint ennek kézi elvégzése hónapokig tartó mérnöki munkát igényelt volna. A csapat ezért először szabványosította a DAO-k átalakítását egy leválasztott MutationConverter interfésszel. Ez a megközelítés külön egységekbe szervezi a Spanner-séma fordítását, így az adattáblák nevei és az oszlop-hozzárendelések nem kerülnek közvetlenül az alapvető DAO-logikába.

A szabványosított szerződés a DAO és a Spanner SDK között pontos célstruktúrát adott az AI-kódoló ügynöknek. A Google példája szerint a konverter kezeli a beszúrási és frissítési mutációkat, ellenőrzi az üres entitásokat, valamint olyan mezőket is leképez, mint az átutalási azonosító, az összeg, a pénznemkód és az utolsó módosítás időpontja.

A headless mód a teljes folyamatot automatizálta

A csapat egy migration_ui.py nevű vezérlőszkriptet épített, amely az Antigravity CLI-t headless módban, a -p kapcsolóval futtatja. Így az eszköz shellszkriptekből, folyamatos integrációs folyamatokból és háttérben futó automatizálási feladatokból is használható, interaktív terminálkérések nélkül.

A promptokat verziókezelt mérnöki artefaktumként kezelték. Az újrafelhasználható sablonok olyan Spanner-specifikus eseteket is rögzítettek, mint az időbélyegek szerializálása, a null értékek kezelése, a mutációk egyértelműsége és a FakeTimeSource tesztforrás beillesztése.

A szkript megkapja a cél-DAO nevét, betölti a meglévő egyszeres írási forráskódot és a sémát, majd ezeket a strukturális konvenciókkal együtt átadja az Antigravitynak. Az eszköz létrehozza az új konvertert, átalakítja a DAO-t párhuzamos írásra, és elkészíti a hozzá tartozó egységteszteket. Ezután a folyamat lefuttatja a blaze test . parancsot. Linterhiba vagy sikertelen teszt esetén a hibanapló visszakerül az Antigravityhoz, amely megpróbálja kijavítani a problémát.

A Google beszámolója szerint a mérnökök akár 10 DAO-t is sorba állíthattak a nap végén. A folyamat éjszaka generálta, tesztelte és ellenőrizte a változtatásokat, így reggelre emberi kódellenőrzésre kész changelist-ek álltak rendelkezésre.

A megközelítés a fejlesztők munkáját is átrendezte

A Google szerint az Antigravity CLI és a Spanner kombinációja jelentősen csökkentette a migrációhoz szükséges kézi kódolást és tesztelést. Az egységes MutationConverter-minta, valamint a Spanner tesztdupláival végzett automatizált ellenőrzés a csapat állítása szerint magas adathűséget biztosított a kiterjedt migrációs tesztek során.

A mérnökök így kevesebb időt töltöttek ismétlődő, sablonos refaktorálással, és több figyelmet fordíthattak az adatmodellezésre, az architektúra ellenálló képességére és a teljesítményhangolásra. A Google három irányelvet emel ki: először le kell választani a sémafordítást, az ismétlődő módosításokat érdemes interaktív csevegés helyett headless automatizálással végrehajtani, a generálási ciklust pedig közvetlenül a build- és tesztkörnyezethez kell kapcsolni.

A cikket Sachin Mathapati, a Google alkalmazásmérnöke jegyzi, és a Google Cloud 2026. szeptember 5-én tette közzé. A bemutatott folyamat a forrás szerint pénzügyi rendszerek migrációjánál és felhőalapú alkalmazások fejlesztésénél is használható kiindulópontként.