Databricks раскрывает детали ветвления Lakebase для параллельных кодирующих агентов

Databricks 8 октября 2026 года опубликовал сообщение в блоге, в котором описан процесс разработки, при котором каждый параллельный кодирующий агент и каждый запрос на слияние работают со своей изолированной, эфемерной базой данных Postgres, созданной с помощью копирования при записи ветвления, встроенного в его Lakebase сервис баз данных.

В статье Databricks описывает базу данных как часто упускаемую из виду часть процесса разработки в то время, когда кодирующие агенты берут на себя всё большую долю работы, а запуск нескольких агентов параллельно становится нормой. При традиционных совместных средах, таких как единая база данных разработки или промежуточная (staging) база, одновременно работающие агенты могут конфликтовать при изменениях схемы, мешать друг другу или полагаться на заглушки, не отражающие реальные данные. Как отмечает статья, эти проблемы уже были болезненными для разработчиков, но агенты усиливают их, поскольку работают быстрее, параллельно и нуждаются в безопасной среде, которая не ставит под угрозу производственные данные и не раскрывает конфиденциальную информацию.

Механика ветвления

Databricks утверждает, что ветвление Lakebase позволяет пользователю создать ветку всей базы данных менее чем за секунду, независимо от её размера. Ветки используют хранилище copy‑on‑write: новая ветка наследует схему и данные родителя, одновременно используя общее хранилище и потребляя дополнительное место только при отклонениях. Согласно Документация по ветвлению Lakebase от Databricks, каждый проект создаётся с веткой по умолчанию под названием production, и у каждой ветки, кроме корневой, есть родитель. Изменения в дочерней ветке никогда не влияют на родительскую, а изоляция распространяется на состояние ролей Postgres: роли и базы данных, созданные, применённые GRANT и REVOKE, а также изменённые атрибуты ролей в одной ветке не оказывают влияния на другие ветки.

Каждая ветка имеет собственные вычислительные ресурсы, масштабируется до нуля в режиме простоя и оплачивается только за активные часы вычислений, как указано в документации. Платёж за хранилище зависит от того, истекает ли срок действия ветки: ветка с истекающим сроком оплачивается только за изменённые данные, тогда как постоянная ветка без истечения срока оплачивается за весь объём данных, как независимая база. Сброс ветки, который обновляет дочернюю ветку из родительской, работает в одном направлении — от родителя к дочерней. Восстановление в определённый момент времени создаёт новую корневую ветку из исторических данных в пределах окна восстановления, оставляя оригинальную ветку неизменной и работающей.

На странице продукта Databricks описывает Lakebase как полностью управляемый, безсерверный сервис Postgres, который использует открытый движок Postgres, а не форк.

Ветка на каждый агент

В статье описанный процесс сочетает рабочие деревья Git с ветвями Lakebase. Рабочее дерево предоставляет каждому агенту собственный каталог со своей проверенной веткой, устраняя конфликты на уровне файлов между агентами, а пост‑checkout‑hook автоматически создаёт ветку базы данных для каждого нового рабочего дерева. В примере, построенном с помощью Claude Code, агент запускает claude -worktree feature-123, Git создаёт рабочее дерево, срабатывает hook, и агент получает собственный каталог кода и полностью изолированную базу данных. Файлы инструкций репозитория, такие как AGENTS.md или CLAUDE.md, направляют поведение агента, а после завершения агент открывает запрос на слияние, после чего и рабочее дерево, и ветка базы данных могут быть удалены.

Одно отличие от Git, отмечает статья, состоит в том, что ветки Lakebase не сливаются обратно в основную ветку, поскольку родитель и потомок могут изменяться независимо, и согласование их данных может быстро стать непрактичным. Вместо этого изменения схемы отслеживаются в коде вместе с логикой приложения и продвигаются в родительскую ветку посредством миграций, используя такие инструменты, как Drizzle, Flyway, Liquibase или Alembic. В примере используется Drizzle: когда требуется изменение схемы, агент добавляет соответствующую миграцию в кодовую базу, а автоматизация развертывания применяет её при деплое предварительного приложения и снова, когда изменение сливается в main.

Ветка на каждый запрос на слияние

Для непрерывной интеграции статья описывает рабочий процесс GitHub Actions, в котором открытие запроса на слияние в main инициирует Lakebase CLI для создания эфемерной ветки, названной в честь запроса на слияние, как дочерней ветки production, и эта ветка становится средой базы данных для запроса. Инструмент миграции запускается против новой ветки, предварительное приложение разворачивается и подключается к строке соединения ветки, а дифф схемы генерируется и публикуется как комментарий к запросу, показывая точно, какие таблицы, столбцы или индексы изменились. Когда запрос закрывается или сливается, автоматизация удаляет ветку. Поскольку ветка создаётся из production, миграцию схемы можно применить и протестировать до того, как изменение попадёт в production. В примере предварительные версии разворачиваются на Databricks Apps, хотя статья утверждает, что концепция применима к другим хостинговым платформам, таким как Vercel, Netlify и Cloudflare.

В отношении окружений статья отмечает, что типичная настройка Lakebase использует один рабочий пространство Databricks на каждое окружение, например разработку, промежуточную (staging) и производство, и команды обычно ветвятся от предварительно заполненной базы данных, а не от производственной, чтобы избежать раскрытия конфиденциальных данных, таких как персональные данные (PII). В демонстрации используется одно рабочее пространство для простоты, при этом подчеркивается, что те же концепции применимы к многоруковым (multi‑workspace) настройкам.

Воспроизведение ошибок и тестирование миграций

Помимо циклов per-agent и per-pull-request, в статье описываются ветвящиеся рабочие процессы, которые не реализованы в примере репозитория. Разработчик может создать изолированную ветку из продакшн‑окружения в определённый момент времени, обычно непосредственно перед появлением бага, воспроизвести и исследовать проблему на реальных данных, а затем удалить ветку после подтверждения исправления. Команды также могут создать ветку перед развертыванием в продакшн, применить миграцию схемы, запустить тесты и убедиться, что приложение продолжает работать как ожидается, прежде чем продвигать изменение. Эти рабочие процессы позволяют разработчикам работать с данными, похожими на продакшн или полученными из продакшн, используя, например, маскирование Unity Catalog, без риска для живой базы данных, сообщает статья.

В статье приводится ссылка на пример репозитория на GitHub, в каталоге Lakebase-Agentic-CI репозитория databricks/tmm, где находятся примеры workflow GitHub Actions, реализующие этот шаблон. Делается вывод, что вместе эти шаблоны образуют то, что автор называет циклом разработки Lakebase: ветка на каждый агент, ветка на каждый pull‑request и изолированные ветки для проверки в продакшн.