Lakebase und agentenbasierter SDLC: Datenbank-Branching für Coding-Agenten

KI hat die Art und Weise verändert, wie Software entwickelt wird. Da Coding-Agenten einen immer größeren Teil der Entwicklungsarbeit übernehmen, gehen Entwickler zunehmend dazu über, diese zu orchestrieren. Das parallele Ausführen mehrerer Agenten wird zur Norm, und die Tooling-Landschaft hat sich entsprechend weiterentwickelt – von Skills und Hooks bis hin zu MCPs und Subagenten, die alle darauf ausgelegt sind, Agenten sicherer und effektiver zu machen.

Dennoch wird ein geschäftskritischer Teil des Entwicklungs-Workflows nach wie vor oft übersehen: die Datenbank.

Jeder gleichzeitig ausgeführte Agent muss Code schreiben, Schemaänderungen anwenden und Tests gegen eine Datenbank ausführen. Bei gemeinsam genutzten Umgebungen, wie etwa einer einzelnen Entwicklungs- oder Staging-Datenbank, die für traditionelle Datenbank-Setups typisch ist, führt dies zu echten Herausforderungen. Agenten können bei Schemaänderungen in Konflikt geraten, sich gegenseitig stören oder auf Mocks zurückgreifen, die nicht die echten Daten widerspiegeln. Dies waren bereits Schmerzpunkte für Entwickler, aber durch Coding-Agenten werden sie noch verstärkt. Agenten agieren schneller, arbeiten parallel und benötigen eine sichere Umgebung, um Produktionsdaten nicht zu gefährden oder sensible Daten preiszugeben.

Die Lakebase Postgres-Architektur löst dies durch Datenbank-Branching. Genauso wie Sie mit Git Code verzweigen können, ermöglicht Ihnen Lakebase das Verzweigen einer gesamten Datenbank in unter einer Sekunde – unabhängig von ihrer Größe. Es nutzt Copy-on-Write, sodass Branches die Daten des Parent-Branch teilen und nur dann zusätzlichen Speicherplatz verbrauchen, wenn sie voneinander abweichen. Zudem können sie auf Null skalieren („scale-to-zero“), was bedeutet, dass inaktive Branches keine Compute-Kosten verursachen. Das ist wichtig, wenn Sie mehrere Agenten gleichzeitig ausführen. Jeder Branch ist vollständig isoliert, sodass ein Agent Migrationen anwenden, Tests ausführen und den Branch stilllegen kann, wenn er fertig ist.

In diesem Artikel zeige ich Ihnen, wie das in der Praxis mit einem End-to-End-Workflow für einen Lakebase-Entwicklungsloop aussieht, der um Coding-Agenten herum aufgebaut ist. Ein Beispiel-Repository steht hier mit Beispielen für GitHub Actions-Workflows zur Verfügung, um das in den folgenden Abschnitten Beschriebene umzusetzen.

Möchten Sie es lieber in Aktion sehen? Schauen Sie sich die Video-Anleitung unten an.

Bevor wir loslegen, noch ein Hinweis zu Umgebungen mit Databricks. Ein gängiges Setup bei der Verwendung von Lakebase Postgres besteht darin, einen Databricks Workspace pro Umgebung zu nutzen, z. B. Dev, Staging und Prod. Die meisten Teams werden Workspaces aus verschiedenen Gründen wie Sicherheit und Compliance nutzen wollen, obwohl es auch möglich ist, einen einzelnen Workspace zu verwenden. Ebenso ist das Verzweigen von einer vorausgefüllten (seeded) Datenbank anstelle der Produktionsdatenbank üblich, um die Offenlegung sensibler Daten wie PII zu vermeiden. In diesem Artikel verwenden wir der Einfachheit halber einen einzelnen Workspace, aber dieselben Kernkonzepte gelten auch für Multi-Workspace-Setups und können ebenso einfach implementiert werden.

Sichere, isolierte Datenbanken für parallele Coding-Agenten

Die größte Veränderung gegenüber traditionellen Datenbanken entsteht durch das gleichzeitige Arbeiten mehrerer Coding-Agenten. Wenn neue Features entwickelt oder Fehler behoben werden, muss jeder Agent oft das Datenbank-Schema lesen, Änderungen anwenden, Testdaten einfügen (seed data) und Tests ausführen. Ohne Isolierung können sich diese Agenten gegenseitig stören oder eine gemeinsam genutzte Datenbank beschädigen. Datenbank-Branching bietet jedem Agenten eine isolierte Umgebung, um unabhängig zu arbeiten, ohne andere gleichzeitig laufende Agenten zu beeinträchtigen.

Eine praktische Möglichkeit, Codekonflikte lokal zu vermeiden, ist die Nutzung von Git-Worktrees. Ein Worktree gibt jedem Agenten sein eigenes Verzeichnis mit einem eigenen ausgecheckten Branch, sodass keine Konflikte auf Dateiebene entstehen. Git-Worktrees lösen die Code-Isolierung für parallele Agenten. Lakebase-Branching löst die andere Hälfte: die Datenbank-Isolierung. Durch das Hinzufügen eines Post-Checkout-Hooks zum Repository erhält jeder neue Worktree automatisch seinen eigenen Datenbank-Branch. Sobald die Entwicklung abgeschlossen ist, öffnet der Agent einen PR. Das Verhalten des Agenten kann über Repository-Anweisungsdateien wie AGENTS.md oder CLAUDE.md gesteuert werden.

Hier ist ein Beispiel-Workflow mit Claude Code, Worktrees und Lakebase-Branching für sichere KI-Entwicklung:

• Agent führt claude -worktree feature-123 aus
• Git erstellt einen Worktree für den Branch feature-123
• Ein Post-Checkout-Hook wird automatisch ausgelöst und erstellt einen Datenbank-Branch
• Der Agent verfügt nun über ein eigenes Code-Verzeichnis und eine eigene, vollständig isolierte Datenbank

Wenn der Agent fertig ist, erstellt er einen PR. Dieses Verhalten wird in der Repository-Anweisungsdatei vorgegeben. Sobald der PR erstellt ist, können sowohl der Worktree als auch der Datenbank-Branch stillgelegt werden. Ein wichtiger Unterschied zu Git besteht darin, dass Lakebase-Branches nicht in den Main-Branch zurückgeführt (gemerged) werden. Da sich Parent und Child unabhängig voneinander ändern können, kann ein Abgleich ihrer Daten schnell unpraktisch werden. Stattdessen werden Schemaänderungen zusammen mit der Anwendungslogik im Code nachverfolgt und dann über Migrationen mit Tools wie Drizzle, Flyway, Liquibase oder Alembic in den Parent-Branch übernommen.

In unserem Beispiel verwenden wir Drizzle. Wenn eine Schemaänderung erforderlich ist, fügt der Agent die entsprechende Migration zur Codebasis hinzu. Die Bereitstellungsautomatisierung wendet diese Migration dann bei der Bereitstellung der Preview-Anwendung an sowie erneut, wenn die Änderung in den Main-Branch gemerged wird.

Ephemere Datenbanken für jeden Pull Request

Sobald ein Pull Request (PR) geöffnet wird, möchten wir den Code automatisch anhand einer echten Datenbank validieren und testen, bevor irgendetwas in die Produktion gelangt.

Mithilfe von Continuous-Integration-Tools (in diesem Fall GitHub Actions) wird für jeden PR ein ephemerer Lakebase-Branch als Child des Produktions-Branchs erstellt. Dieser Branch wird zur Datenbankumgebung für den PR. Automatisierte Tests können darauf ausgeführt, eine Preview-Anwendung bereitgestellt und Reviewer können die Änderung anhand einer echten Datenbank validieren.

Da der Branch von der Produktion ausgeht, kann die Schemamigration ebenfalls angewendet und getestet werden, bevor die Änderung die Produktion erreicht.

Sobald der PR genehmigt und gemerged ist, werden der Feature-Code und die Migrationsanweisungen übernommen und der temporäre Lakebase-Branch wird gelöscht.

Ein typischer GitHub Actions-Workflow sieht folgendermaßen aus:

• Ein PR wird für den Main-Branch geöffnet
• Die CI ruft die Lakebase CLI auf, um einen Branch wie pr-123 zu erstellen
• Das Migrations-Tool (Drizzle, Alembic usw.) läuft auf dem neuen, dedizierten Datenbank-Branch
• Eine Preview-App wird bereitgestellt, die auf den Connection-String des Branchs verweist
• Ein Schema-Diff wird generiert und als PR-Kommentar gepostet, der genau zeigt, welche Tabellen, Spalten oder Indizes sich geändert haben
• Der Reviewer validiert sowohl den Code als auch die Datenbankänderungen
• Wenn der PR geschlossen oder gemerged wird, löscht die CI den Branch

Im Repository-Beispiel stellen wir die Anwendung mit Databricks Apps bereit, aber das Konzept gilt auch für alle anderen Hosting-Plattformen wie Vercel, Netlify, Cloudflare und mehr.

Fehlerreproduktion, Migrationen und Tests mit Datenbank-Branches

Über Entwicklungsaufgaben hinaus kann Datenbank-Branching mehrere weitere nützliche Workflows unterstützen. Diese sind im Beispiel-Repository nicht implementiert, können aber wertvolle Ergänzungen für einen Lakebase-Entwicklungs-Workflow sein. Beispielsweise können Sie mit Datenbank-Branching zu einem bestimmten Zeitpunkt einen isolierten Branch aus der Produktion erstellen – typischerweise direkt bevor ein Fehler aufgetreten ist –, das Problem anhand der echten Daten untersuchen, den Fehler sicher reproduzieren und den Branch löschen, sobald die Behebung validiert ist.

Branching kann auch Schema-Migrationen sicherer machen. Bevor Sie eine Änderung in der Produktion bereitstellen, können Sie automatisch einen Datenbank-Branch erstellen, die Migration anwenden, Tests ausführen und überprüfen, ob sich die Anwendung weiterhin wie erwartet verhält. Sobald die Migration validiert ist, kann dieselbe Änderung in die Produktion übernommen werden.

Diese Workflows sind besonders leistungsfähig, da Entwickler mit produktionsnahen oder aus der Produktion abgeleiteten Daten arbeiten können – beispielsweise unter Verwendung von Unity Catalog-Maskierung –, ohne die Live-Datenbank zu gefährden. Jeder Branch ist isoliert und flüchtig, was ihn zu einer sicheren Umgebung für Debugging, Tests und Validierung macht.

Fazit

Zusammen bilden diese Muster den Lakebase-Entwicklungszyklus: ein Branch pro Agent, ein Branch pro PR und isolierte Branches für die Produktionsvalidierung.

Für den Agentic SDLC bietet Datenbank-Branching eine sichere und flexible Grundlage für Entwicklungsteams, die mit Coding-Agenten arbeiten. Probieren Sie Branching am besten selbst aus.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag