Databricks podrobně popisuje větvení Lakebase pro paralelní kódovací agenty

Databricks 8. října 2026 zveřejnil blogový příspěvek, který podrobně popisuje vývojový workflow, ve kterém každý paralelní kódovací agent a každý pull request běží na své vlastní izolované, efemérní databázi Postgres, vytvořené pomocí copy‑on‑write větvení zabudovaného v jeho Lakebase databázové službě.

V příspěvku Databricks popisuje databázi jako často přehlíženou součást vývojového workflow v době, kdy kódovací agenti přebírají rostoucí podíl vývojové práce a provoz více agentů paralelně se stává normou. U tradičních sdílených prostředí, jako je jediná vývojová nebo testovací databáze, mohou souběžní agenti kolidovat při změnách schématu, navzájem si překážet nebo se spoléhat na mocky, které neodrážejí reálná data. Tyto problémy už byly pro vývojáře obtížné, uvádí příspěvek, ale agenti je zhoršují, protože pracují rychleji, fungují paralelně a potřebují bezpečné prostředí, které neohrožuje produkční data ani neodhaluje citlivá data.

Mechanika větvení

Databricks uvádí, že větvení Lakebase umožňuje uživateli vytvořit větev celé databáze za méně než sekundu, bez ohledu na její velikost. Větve využívají úložiště copy‑on‑write: nová větev dědí schéma a data svého rodiče, přičemž sdílí podkladové úložiště a spotřebovává další úložný prostor jen při odchylkách. Podle dokumentace k větvení Lakebase od Databricks je každý projekt vytvořen s výchozí větví pojmenovanou production a každá větev kromě kořenové má rodiče. Změny v podřízené větvi nikdy neovlivní její rodičovskou větev a izolace se vztahuje i na stav rolí v Postgresu: role a databáze vytvořené, GRANTy a REVOKEy aplikované a atributy rolí upravené v jedné větvi nemají žádný dopad na ostatní větve.

Každá větev má vlastní výpočetní prostředky, škáluje na nulu při nečinnosti a je účtována pouze za aktivní výpočetní hodiny, uvádí dokumentace. Účtování úložiště závisí na tom, zda větev expiruje: expirovaná větev je účtována jen za data, která na ní byla změněna, zatímco trvalá větev bez expirace je účtována za celou velikost svých dat, podobně jako samostatná databáze. Reset větve, který obnoví podřízenou větev z jejího rodiče, funguje jen jedním směrem – od rodiče k podřízené. Obnova k určitému okamžiku vytváří novou kořenovou větev z historických dat v rámci obnovovacího okna, přičemž původní větev zůstává nezměněna a funkční.

Na její produktové stránce Databricks popisuje Lakebase jako plně spravovanou, serverless službu Postgres, která běží na open‑source enginu Postgres místo forku.

Jedna větev na agenta

Workflow v příspěvku spojuje Git worktree s větvemi Lakebase. Worktree poskytuje každému agentovi jeho vlastní adresář s vybranou větví, čímž odstraňuje souborové konflikty mezi agenty, a po‑checkout hook pak automaticky vytvoří databázovou větev pro každý nový worktree. V příkladu, postaveném pomocí Claude Code, agent spouští claude -worktree feature-123, Git vytvoří worktree, hook se spustí a agent tak získá svůj vlastní adresář s kódem a plně izolovanou databázi. Souborové instrukce v repozitáři, jako AGENTS.md nebo CLAUDE.md, řídí chování agenta a po dokončení agent otevře pull request, po kterém lze jak worktree, tak databázovou větev vyřadit.

Jedním rozdílem oproti Gitu, uvádí příspěvek, je to, že větve Lakebase se nevrací zpět do hlavní větve, protože rodič a potomek se mohou měnit nezávisle a sladění jejich dat se může rychle stát nepraktickým. Místo toho jsou změny schématu sledovány v kódu spolu s logikou aplikace a propagovány do hlavní větve pomocí migrací, s využitím nástrojů jako Drizzle, Flyway, Liquibase nebo Alembic. Příklad používá Drizzle: když je potřeba změna schématu, agent přidá odpovídající migraci do kódu a automatizace nasazení ji aplikuje při nasazení preview aplikace a znovu, když se změna sloučí do hlavní větve.

Jedna větev na pull request

Pro kontinuální integraci příspěvek popisuje workflow GitHub Actions, ve kterém otevření pull requestu proti hlavní větvi spustí Lakebase CLI k vytvoření efemérní větve, pojmenované podle pull requestu, jako podřízené větve produkce, a tato větev se stane databázovým prostředím pull requestu. Nástroj pro migraci běží proti nové větvi, nasadí se preview aplikace a nasměruje se na připojovací řetězec větve, a vygeneruje se diff schématu, který se zveřejní jako komentář k pull requestu a ukazuje přesně, které tabulky, sloupce nebo indexy se změnily. Když je pull request uzavřen nebo sloučen, automatizace větev smaže. Protože větev vychází z produkce, lze migraci schématu aplikovat a otestovat před tím, než změna dorazí do produkce. Příklad nasazuje preview na Databricks Apps, ačkoliv příspěvek uvádí, že koncept platí i pro jiné hostingové platformy jako Vercel, Netlify a Cloudflare.

V souvislosti s prostředími příspěvek poznamenává, že běžné nastavení Lakebase používá jeden Databricks workspace na prostředí, například vývoj, testování a produkci, a že týmy často vytvářejí větve z naplněné databáze místo z produkční databáze, aby se vyhnuly odhalení citlivých údajů, jako jsou osobní údaje (PII). Průvodce používá pro zjednodušení jeden workspace, přičemž upozorňuje, že stejné koncepty platí i pro nastavení s více workspaces.

Reprodukce chyby a testování migrací

Mimo smyčky na úrovni agenta a požadavku na sloučení (pull request) příspěvek popisuje větvení pracovních postupů, které nejsou v ukázkovém repozitáři implementovány. Vývojář může vytvořit izolovanou větev z produkce v konkrétním okamžiku, obvykle těsně před tím, než se objevil bug, reprodukovat a prozkoumat problém na reálných datech a větev ukončit, jakmile je oprava ověřena. Týmy mohou také vytvořit větev před nasazením do produkce, aplikovat migraci schématu, spustit testy a ověřit, že aplikace se stále chová podle očekávání, předtím než změnu propagují. Tyto pracovní postupy umožňují vývojářům pracovat s daty podobnými produkci nebo odvozenými z produkce, například pomocí maskování Unity Catalog, aniž by ohrozili živou databázi, uvádí příspěvek.

Příspěvek odkazuje na ukázkový repozitář na GitHub, ve složce Lakebase-Agentic-CI repozitáře databricks/tmm, který obsahuje příklady workflow GitHub Actions implementujících tento vzor. Závěrem konstatuje, že tyto vzory společně tvoří to, co nazývá vývojovou smyčkou Lakebase: větev na agenta, větev na pull request a izolované větve pro validaci v produkci.