Google автоматизировала dual-write миграцию на Spanner через Antigravity CLI

Миграция без остановки потребовала временно жить в двух базах

Finance Engineering внутри Google переносит устаревший data layer на Spanner — глобально распределённую, strongly consistent multi-model database. Обычный cutover для такого сервиса не подходил: финансовые записи должны оставаться точными, а production нельзя просто выключить на время переноса. Поэтому команда выбрала многоэтапную схему с историческим backfill, параллельной записью и чтением, а затем автоматической проверкой того, что обе системы получают одинаковые изменения.

Самый дорогой участок оказался не в копировании старых строк, а в однообразных правках application code. Для каждого Data Access Object требовались преобразование доменной модели в Spanner schema, ветка dual-write с обработкой ошибок и набор unit tests с test doubles и FakeTimeSource. Таких DAO было больше тридцати. По оценке авторов, ручная переделка заняла бы месяцы и оставила бы много возможностей для расхождения между похожими реализациями.

Сначала команда сузила задачу до жёсткого контракта

Перед подключением coding agent инженеры стандартизировали целевую архитектуру. Перевод полей и типов вынесли из бизнес-логики DAO в отдельный интерфейс MutationConverter. Вместо того чтобы каждый объект самостоятельно собирал spanner.Mutation, он обращается к ограниченному преобразователю с понятным входом и ожидаемым результатом. Агенту досталась не открытая просьба «перепиши миграцию», а повторяемая трансформация по заранее принятому шаблону.

Это важнее выбора конкретной модели. Автоматизация становится надёжнее, когда команда заранее фиксирует границы изменений, структуру создаваемых файлов и проверяемые инварианты. В случае Google такими инвариантами были единый converter pattern, параллельная запись и тесты обеих веток. Antigravity CLI не должен был самостоятельно изобретать data architecture; он масштабировал уже принятое инженерное решение на множество однотипных участков кода.

Headless mode превратил агента в шаг build pipeline

Интерактивный чат в IDE удобен для исследования одной задачи, но плохо подходит для серийной обработки десятков файлов. Команда написала orchestration script migration_ui.py и запускает Antigravity CLI в headless mode с флагом -p. Скрипт получает имя целевого DAO, исходный single-write code и схему, добавляет структурные правила, а затем просит инструмент создать converter, переработанный dual-write DAO и соответствующие unit tests.

После генерации конвейер запускает blaze test. Ошибка линтера, компиляции или assertion не превращается сразу в незавершённый changelist: журнал возвращается Antigravity для следующей попытки исправления. За счёт этого цикл generation → build → correction выполняется без ручных terminal prompts. Инженер подключается позже, когда артефакт уже прошёл машинные ограничения и готов к содержательному code review.

Prompts стали версионируемыми инженерными артефактами

Команда вынесла повторяющиеся требования в reusable prompt templates и хранит их как version-controlled artifacts. В правила вошли обработка timestamp, nullability conversions, неоднозначности при построении mutation и внедрение FakeTimeSource в тесты. Такой prompt описывает не настроение диалога, а контракт преобразования: одинаковые edge cases должны получать одинаковую обработку независимо от выбранного DAO.

Практический эффект — возможность пакетной работы. В конце дня инженеры ставят в очередь десять DAO, а к утру получают десять сгенерированных, протестированных и проверенных changelists для review. Официальная публикация не приводит абсолютное время на один объект, стоимость inference или процент попыток, которые потребовали ручной переработки. Поэтому результат нельзя переносить на любую кодовую базу как готовый benchmark, но схема показывает, как сделать длительную агентную работу воспроизводимой и наблюдаемой.

Data parity остаётся главным критерием, а не скорость генерации

Для финансового сервиса успешный compile недостаточен. Во время migration window обе базы должны получать идентичные writes, пока завершается backfill и проверка исторических данных. Google описывает перехват RPC traffic и end-to-end parity checking с byte-for-byte сравнением записей. Именно этот слой отделяет быстро написанный dual-write code от доказательства, что переход не меняет финансовое состояние системы.

Авторы сообщают о высокой data fidelity в расширенном migration testing и о заметном сокращении усилий: операции, которые раньше требовали большого объёма ручного coding и testing, завершались и проходили review за долю прежнего времени. При этом текст прямо говорит о staging environments и подготовке к production. Это существенное ограничение: статья описывает подтверждённое ускорение инженерной подготовки, но не объявляет завершённый production cutover и не публикует независимый аудит точности.

Подход переносим только вместе с ограничителями

Из опыта команды следуют три шага. Сначала нужно отделить schema translation от основной логики и определить строгий интерфейс. Затем повторяющиеся изменения следует вынести из чата в headless workflow. Наконец, generation loop необходимо связать со сборкой и тестами — будь то bazel test, go test или другой штатный harness. Тогда модель получает объективную обратную связь раньше, чем результат увидит reviewer.

Однако даже хороший pipeline не отменяет архитектурный review, контроль rollback и независимую сверку данных. Агент может последовательно воспроизвести ошибку, если исходный шаблон неверен, а зелёные unit tests не доказывают полноту production traffic. Ценность решения Google не в обещании автономной миграции, а в разделении ответственности: люди задают контракт и критерии parity, CLI тиражирует изменения, build system отсеивает технические дефекты, а reviewer принимает готовый changelist.