Evolutionäre Datenbankentwicklung ermöglichen: Datenbank-Branching mit Lakebase – das Fazit

Die in Evolutionary Database Design beschriebene und in Refactoring Databases: Evolutionary Database Design operationalisierte Methodik ist seit zwanzig Jahren etabliert. Die sieben Praktiken, der Katalog mit über 70 benannten Refactorings, die Übergangsmechanismen – all das ist dokumentiert, von Experten geprüft und gelehrt.

Diese Methodik erreichte CI/CD im Jahr 2010 mit Continuous Delivery (Kapitel 12: Managing Data). Migrationen wurden zu erstklassigen Artefakten in der Deployment-Pipeline. Die Disziplin „Database-Changes-as-Code“ erreichte die breitere CI/CD-Bewegung. Was CD nicht löste, war die Isolation pro Pipeline: Pipelines konnten zwar Migrationen ausführen, benötigten aber immer noch eine Zieldatenbank, und diese Zieldatenbank wurde gemeinsam genutzt. Praktik #4 – Jeder bekommt seine eigene Datenbankinstanz – blieb in den meisten Teams ein Wunschtraum, da echte, produktionsnahe Datenbanken pro Entwickler Zeit, Geld und DBA-Zyklen kosten. Die Behelfslösungen, die entstanden, um diese Lücke zu schließen (Mock-Objekte, gemeinsam genutzte Staging-Umgebungen, In-Memory-Datenbank-Ersatz, DBA-Ticket-Queues), wurden standardmäßig zur grundlegenden Methodik – allerdings ungewollt, nicht durch bewusstes Design.

Im Jahr 2026 hält das Copy-on-Write-Datenbank-Branching Einzug in Databricks Lakebase. Das Erstellen eines Branches einer produktiven Datenbank im Terabyte-Bereich in nur einer Sekunde und ohne anfänglichen Speicherbedarf ist nun eine O(1)-Operation. Die Einschränkung, die Praktik #4 zu einem bloßen Wunschtraum machte, ist damit aufgehoben.

Diese Serie beschreibt, was sich ändert, wenn diese Einschränkung wegfällt: nicht die Methodik selbst – diese bleibt bestehen –, sondern die Praktiken, die dadurch erst möglich werden, die Governance auf Teamebene, die sich automatisiert, die Weiterentwicklung der Rolle des DBA und die neue Arbeitsgrundlage, die sich Agenten mit ihren menschlichen Kollegen teilen.

Lernen Sie Jen kennen

Jen ist die Entwicklerin aus Evolutionary Database Design. In diesem Essay implementierte sie ein Datenbank-Refactoring – das Aufteilen eines inventory_code-Felds in location_code, batch_number und serial_number – als ganz normale User Story. Sie zeigte damit, dass DBAs und Entwickler erfolgreich zusammenarbeiten, Schemata sich in kleinen Schritten weiterentwickeln und Migrationen Änderungen sicher übertragen können.

Die Serie knüpft zwanzig Jahre später wieder bei Jen an. Die Methodik, der sie folgt, ist dieselbe wie im Jahr 2003. Neu ist die technologische Grundlage unter ihrem Workflow: Copy-on-Write-Datenbank-Branching, das die Praktiken, über die sie bisher nur gelesen hat, im Produktivbetrieb in großem Maßstab realisierbar macht. In den drei Teilen dieser Serie erleben wir dieselbe Jen in drei verschiedenen Dimensionen – ihr Arbeitsalltag (Teil 1), ihr neues Playbook (Teil 2) und ihr Team (Teil 3).

Teil 3: Jens Team im großen Maßstab

Teil 1 begleitete Jen bei der Umsetzung eines Features. Teil 2 stellte das Playbook mit elf Praktiken vor, nach dem sie im Jahr 2026 arbeitet. Teil 3 wendet dasselbe Playbook auf ein Team von fünfzig Entwicklern an, in dem Agenten Seite an Seite mit Menschen Branches erstellen, und stellt die Frage: Was wird bei dieser Größenordnung strukturell wichtig?

Drei Aspekte werden dabei tragend.

Erstens die Tier-Topologie, also die langlebigen Branches, die die einzelnen Umgebungen im Freigabepfad darstellen. Bei einem einzelnen Entwickler gab es einen Feature-Branch und die Produktion. Bei fünfzig Entwicklern hat man eine strukturierte Hierarchie mit stabilen und darüber liegenden, kurzlebigen Pfaden.

Zweitens das Berechtigungsmodell – das Framework, das festlegt, wer was auf welchem Branch tun darf. Bei einem einzelnen Entwickler konnte man sich auf Absprachen verlassen. Bei fünfzig Entwicklern, unter denen sich auch Agenten befinden, muss das Framework einmalig entworfen und automatisch durchgesetzt werden.

Drittens die Rolle des DBA. Bei einem einzelnen Entwickler war der DBA Jens Designpartner beim PR. Bei fünfzig Entwicklern ist der DBA der Plattform-Engineer, der das Framework entworfen hat, in dem sich Jen und ihre Teamkollegen bewegen.

Dieser Beitrag behandelt jeden dieser Punkte und widmet sich dann den Agenten. Agenten mit denselben Fähigkeiten einzusetzen, ist Praktik #11. Agenten sind wie Junior-Entwickler: Sie schreiben Code, der läuft, Tests, die erfolgreich sind, und Migrationen, die funktionieren – aber ohne Anleitung erschaffen sie unwartbare Systeme. Durch Tests stellt das Team sicher, dass sie korrekt arbeiten. Das folgende TDD-Playbook zeigt, wie das Team dafür sorgt, dass Tests an erster Stelle stehen.

Tiers als langlebige Branches, nicht als separate Instanzen

In der Welt vor dem Branching war eine Umgebung eine eigene Instanz: ein dediziertes Postgres-Deployment für Staging, ein weiteres für UAT, ein anderes für Performance-Tests – jeweils separat bereitgestellt, gepatcht, maskiert und synchronisiert. Die in Teil 2 erwähnten Behelfslösungen kamen auch hier zum Einsatz. Abweichungen (Drift) zwischen den Umgebungen waren systembedingt.

Auf Teamebene wird das Tier-Modell auf langlebige Branches konsolidiert, die vom selben Lakebase-Parent abzweigen.

Ein Branch ist eines von zwei Dingen: ein Tier (langlebig, ein Parent in der Freigabehierarchie) oder ein Feature (kurzlebig, stammt von einem Tier ab und wird danach gelöscht). Ein Tier hat einen Parent. Die Parent-Of-Kette bildet die Freigabehierarchie.

In Abb. 1 sehen wir eine einfache Hierarchie, bei der „Main“ die Produktion darstellt und Feature-Branches bei Bedarf erstellt werden. Dieses Setup ist im Allgemeinen nützlich für frühes Prototyping oder Arbeiten in der Anfangsphase mit einem sehr kleinen Team. Erfahrene Teams mit mehr Entwicklern und/oder vielen Umgebungen benötigen ein Setup wie unten dargestellt.

In einigen Unternehmen wird ein Release Candidate (RC) benötigt. Dieser Release Candidate befindet sich eine Zeit lang in der Entwicklung und wird nach erfolgreichem Testen in die Produktion überführt. Abb. 3 zeigt ein Layout, das die Entwicklung von Release Candidates und deren spätere Überführung in die Produktion ermöglicht, woraufhin der Release-Candidate-Branch gelöscht werden kann.

Die Namen der Branches sind beliebig. Wichtig sind die Konventionen für die Einrichtung der Parent-Of-Beziehungen. Es kann eine Richtlinie implementiert werden, die Übergänge verhindert, die der Hierarchie der Parent-Kette widersprechen, um einen direkten Feature-Merge zu verhindern.

Die Richtliniendefinitionen bieten viele Vorteile für das Pipeline-Management:

• Eine Pipeline-Definition, die Branches berücksichtigt. Die in Teil 2 eingeführte pr.yml läuft bei jedem PR; die merge.yml läuft bei jeder Freigabe (Promotion). Derselbe Workflow deckt Features, Tiers und die Übergänge dazwischen ab.
• Freigabe (Promotion) ist ein Merge, kein erneutes Deployment. Die Bereitstellung von Staging auf Produktion ist ein Git-Merge, dessen nachgelagerter Effekt eine Lakebase-Branch-Promotion ist. Die Migration wird auf jedem Tier einmal angewendet und zuerst auf dem vorherigen Tier validiert – genau wie Code, der in früheren Phasen validiert wird.
• Keine Abweichungen (Drift) zwischen „der Testumgebung“ und der Produktion. Jedes Tier stammt vom selben Parent ab. Der Schema-Unterschied (Diff) zwischen zwei beliebigen Tiers ist real und berechenbar: Das Schema ist eine einzige Kette von Seiten mit Abweichungsmarkierungen, nicht zwei separate Installationen von Datenbanksoftware. Dadurch müssen Teams keine Flotte von Datenbankservern mehr verwalten, die gepatcht und aktualisiert werden müssen.

Rollback durch Repoint. Eine fehlerhafte Promotion wird behoben, indem die Anwendung auf den Snapshot der Ebene vor der Promotion verwiesen wird. Der Snapshot selbst ist ein weiterer Branch, sodass Teams sich von fehlerhaften Deployments erholen können.

Kostenzuordnung nach project_id, branch_id, endpoint_id. Unity Catalog erfasst Metadaten automatisch. Eine SQL-Abfrage der Audit- und Abrechnungstabellen zeigt, wer welchen Branch wann erstellt hat und wie viel es kostet, den Branch aktiv zu halten.

Auch die große Anzahl an Datenbankinstanzen sinkt drastisch. Eine Welt mit sechs Umgebunginstanzen (prod, staging, UAT, QA, perf, demo) schrumpft zu einem einzigen Lakebase-Parent mit einer hierarchisch verknüpften Struktur langlebiger Branches. Die Instanz, die früher für Bereitstellung, Überwachung und Patching genutzt wurde, ist jetzt ein logischer Branch mit derselben Datenstruktur wie die Produktion. Sie unterliegt denselben Richtlinien wie die Produktion und lässt sich bei Bedarf in einer Sekunde auf den Produktionszustand zurücksetzen.

Verschiedene Konventionen ermöglichen es Ihnen, viele verschiedene Arten von Branches als Parents zu erstellen. Eine gängige Praxis ist es, einen Branch zu pflegen, der das Datenbankschema und alle Referenzdaten enthält. So kann jeder davon abzweigen (branchen), ihn mit Testdaten füllen oder automatisierte Tests ausführen, die echte Daten erzeugen, ohne mit Staging oder anderen Branches in Konflikt zu geraten.

Was jetzt zu tun ist: das Berechtigungsmodell

Praxisbeispiel #10: Im Playbook von Teil 2 haben wir über einmalig definierte Governance, die pro Branch vererbt wird, gesprochen. Sehen wir uns an, wie dies umgesetzt wird.

Die Designarbeit blockiert nicht die Laufzeit. Es handelt sich um ein strukturelles Design, das dann von Routineaufgaben erzwungen werden kann.

Diese Entscheidungen sollten Sie jetzt treffen, bevor das Team wächst oder KI-Agents hinzugefügt werden:

• Erstellen von Branches für jede Ebene. Das Abzweigen (Forken) von der Produktion erfordert andere Berechtigungen als das Forken von Staging oder einem Feature. Der Standard sollte sein: Features zweigen von der untersten Ebene ab, niemals von der Produktion. Produktions-Forks sind für Hotfixes und Recovery-Prozesse reserviert.
• Promotion zwischen den Ebenen. Eine Promotion von „Feature zu Staging“ ist Thema eines Code-Reviews. Eine Promotion von „Staging zu Produktion“ betrifft die Release-Koordination. Dies sind zwei separate Freigabestufen mit unterschiedlichen Reviewern, was Business- und Entwicklungsteams Unabhängigkeit bietet.
• Lesen vs. Schreiben. Der Lesezugriff auf produktionsnahe Daten in einem Branch ist nicht dieselbe Berechtigung wie der Schreibzugriff auf diesen Branch. Viele Engineering-Rollen benötigen Lesezugriff, nur wenige Schreibzugriff.
• Unity Catalog-Richtlinien. Unity Catalog-Richtlinien wie Maskierung, Zeilenfilter und Berechtigungen auf Spaltenebene gelten für die Produktion. Diese Richtlinien werden standardmäßig an jeden untergeordneten Branch vererbt. Ebenenspezifische Ausnahmen (z. B. eine QA-Ebene mit synthetisierten PII für Lasttests) werden einmalig definiert.
• Erfassung von Audit Trails. Jede Branch-Erstellung, jede Promotion, jede angewendete Migration und jedes Zugriffsmuster an einem einzigen, abfragbaren Ort.

Das Prinzip, das dies auf Teamebene ermöglicht: Rollen deklarieren, Richtlinien setzen durch. Der Platform Engineer deklariert die Ebenenhierarchie, das Berechtigungsmodell, die Promotion-Pfade und die Unity Catalog-Richtlinienstruktur. Die Richtlinie lehnt jeden Übergang ab, der der Deklaration widerspricht. Weder Menschen noch Agents können eine deklarierte Grenze umgehen, indem sie den Vorgang in einer anderen Form wiederholen.

Diese Arbeit muss heute erledigt werden, bevor das Team auf fünfzig Entwickler anwächst und Agents Branches schneller erstellen, als ein Mensch sie jemals prüfen könnte. Das Framework hält das Team durch gemeinsame Konventionen und Leitplanken (Guardrails) zusammen. Alles andere bewegt sich innerhalb dieses Rahmens.

Die neue Rolle: Vom DBA zum Platform Engineer

Vor zwanzig Jahren endete der Essay Evolutionary Database Design von 2003 mit folgenden Worten:

„Die Anwendung der hier beschriebenen Techniken mag nach viel Arbeit klingen, erfordert aber tatsächlich nicht viele Leute. Bei vielen Projekten hatten wir etwa dreißig Entwickler und eine Teamgröße (einschließlich QA, Analysten und Management) von fast hundert Personen. An jedem beliebigen Tag hatten wir etwa hundert Kopien verschiedener Schemata auf den Workstations der Mitarbeiter. Dennoch war für all diese Aktivitäten nur ein einziger Vollzeit-DBA erforderlich, zusammen mit ein paar Entwicklern, die die Funktionsweise des Prozesses und des Workflows verstanden.“

Dieses Argument gilt auch im Jahr 2026, gestützt durch fünf neue Aspekte.

1. Das Verhältnis bleibt gleich, mit mehr Spielraum pro DBA. Ein Vollzeit-DBA auf ca. 100 Personen bei gleichzeitig über hundert aktiven Branches verursacht weniger Kosten pro Branch, da die Branch-Erstellung jetzt eine Metadaten-Operation von einer Sekunde ist. Das Verhältnis ist nicht der entscheidende Punkt. Sondern das, was der DBA in dieser Zeit tut.

2. Die Arbeit verlagert sich nach oben. Stunden, die 2003 für die Bereitstellung von Infrastruktur und Schemata, die Zugriffskontrolle und gelegentliche manuelle Eingriffe aufgewendet wurden, fließen heute in das Design von Branching-Richtlinien, Maskierungsrichtlinien, Promotion-Workflows und die Observability von Audit Trails. Die konkreten Ergebnisse: Schema-Diff-Bots, die in jedem PR posten, geplante Jobs, die Entwicklungs-Branches jede Nacht zurücksetzen, Observability-Dashboards zur Verfolgung des Branch-Lebenszyklus und der TTL-Compliance sowie CI-Definitionen, die Merges von einer Schema-Validierung abhängig machen. Dies ist Plattform-Designarbeit – eine weitaus anspruchsvollere Aufgabe als früher.

3. Agents kommen ins Spiel. Womit sich der Essay von 2003 noch nicht befassen musste, waren code-schreibende Agents. Neon berichtet von etwa einer halben Million Branches pro Tag, von denen über 80 % von Agents erstellt werden. Ein einzelner DBA kann dieses Volumen nicht über Tickets steuern. Die Weiterentwicklung der Rolle zum Plattform-Architekten ist der einzige Weg, der im Agent-Maßstab funktioniert.

4. Die Zahlen werden konkret. Ein Team aus sechs Entwicklern erzeugt im alten Modell typischerweise mehr als 30 operative Tickets pro Sprint (Bereitstellung, Schema-Reviews, Datenaktualisierungen, Zugriffsberechtigungen). Im Branch-nativen Modell sind es weniger als 5 hochwertige Richtlinien-Reviews pro Sprint. Der Arbeitsaufwand (Toil) für den DBA sinkt von über 20 Stunden pro Woche auf unter 5, und die MTTR sinkt von über 4 Stunden auf unter 30 Minuten. Diese Entlastung ermöglicht es dem DBA, enger mit den Entwicklern zusammenzuarbeiten, um optimale Lösungen für die entwickelten Features zu finden.

5. Der Audit Trail wird zum strategischen Dashboard. Was früher den Abgleich von drei Diensten und drei Abfragesprachen erforderte, ist heute eine einzige SQL-Abfrage auf den Systemtabellen der Plattform. Jeder Branch, jede Aktion, alle Kosten und jedes Governance-Ereignis an einem Ort. Der DBA muss diese Ansicht nicht manuell erstellen – das übernimmt die Plattform.

Im Vorwort zu Refactoring Databases (2006) hoffte Martin Fowler, dass das Buch „nur einen ersten Schritt“ hin zu Tools darstellt, die das Datenbank-Refactoring so automatisieren, wie IDEs das Code-Refactoring automatisieren. Branching ist dieser nächste Schritt. Was Fowler sich 2006 erhoffte – disziplinierte Datenbankänderungen in der Geschwindigkeit von Code –, bietet die Plattform heute. Der DBA entwirft die Regeln, die Plattform wendet sie an.

Die Bezeichnung der neuen Rolle variiert (Platform Engineer, Database Platform Owner oder dem Namen nach immer noch DBA). Der Kern bleibt derselbe: die Person, die das Framework entwirft, in dem sich alle anderen bewegen.

Agents mit denselben Funktionen

Praxisbeispiel #11: In Teil 2 haben wir den Coding-Agent als Anwender mit derselben Branching-Funktion beschrieben. Lassen Sie uns das näher beleuchten.

Agents erhalten Zugriff auf Branches, nicht auf die Produktion. Für den Agent gelten dieselben Workflow-Regeln wie für Jen. Tests laufen auf einer echten Datenbank in einem Branch, nicht gegen Mocks, die ein Agent ändern oder löschen könnte. Schema-Diffs landen in jedem PR, unabhängig davon, wer die Migration erstellt hat. Die Richtlinien, die Jen schützen, schützen auch den Agent.

Doch Richtlinien allein reichen nicht aus. Ohne Anleitung sind Agents wie Junior-Entwickler.

Ein Junior-Entwickler, der ohne weitere Anleitung ein Feature-Ticket erhält, kann Code schreiben, der kompiliert, Tests, die erfolgreich durchlaufen, und ein Migrationsskript, das sich sauber ausführen lässt. Der Code dupliziert jedoch vielleicht Logik, die bereits an anderer Stelle in der Codebasis existiert, was zu Redundanzen führt. Die Migration fügt eventuell eine Spalte mit dem richtigen Namen, aber dem falschen Typ hinzu. Der Test ist vielleicht nur erfolgreich, weil er nur den „Happy Path“ abdeckt. Keiner dieser Fehler fällt beim grünen CI-Durchlauf auf; sie zeigen sich erst sechs Wochen später, wenn jemand anderes die Arbeit erweitern muss.

Agenten tun dasselbe, aber viel schneller und in viel größerem Umfang.

Ohne explizite Anleitung wird ein Agent:

• Ein Muster neu erfinden, das in der Codebasis bereits vorhanden ist.
• Eine Schemaänderung erstellen, die zwar richtig aussieht, aber die festgelegten Übergangsmechanismen für das Refactoring überspringt (z. B. das Löschen einer Spalte, ohne vorher die Daten zu verschieben, oder das Hinzufügen einer NOT NULL-Spalte, ohne bestehende Zeilen zu aktualisieren).
• Tests schreiben, die für die von ihm angenommene Datenstruktur erfolgreich sind, nicht für die tatsächlich in der Produktion vorhandene Datenstruktur.
• Migrationen erstellen, die sich zwar anwenden lassen, aber bei einem Rollback zu einem inkonsistenten Zustand führen.
• Abstraktionsebenen über Abstraktionsebenen stapeln, nur um eine kleine Änderung umzusetzen.

Das Substrat sorgt dafür, dass der grüne Balken ehrlich ist (keine Mocks; echte Datenbank auf einem Branch). Was es jedoch nicht tut, ist, den Code wartbar zu machen.

Das Team stellt die Wartbarkeit des Codes durch vier Verstärkungen sicher:

• Leitplanken: das Berechtigungsmodell. Agenten können keine Branches von der Produktion erstellen, keine Promotionen zwischen Tiers durchführen und keine Migrationen auf ein Tier anwenden, das ihnen nicht gehört. Das Substrat verweigert dies.
• Muster: die benannten Refactorings. Der Katalog von 2006 unter databaserefactoring.com nennt über 70 Refactorings mit expliziten Übergangsmechanismen. Ein Agent, der angewiesen wird, „das Split-Column-Refactoring anzuwenden“, erzeugt eine andere Migration als ein Agent, der angewiesen wird, „diese Spalte aufzuteilen“.
• Workflow: die SCM-Zustandsmaschine (Source-Control-Management). Agenten folgen einer Abfolge von Zuständen mit blockierenden Gates dazwischen. Das Substrat verweigert Übergänge, die den deklarierten Vertrag nicht erfüllen.
• Review: Menschen im PR-Loop. Schema-Diffs sind bei jedem PR sichtbar, wobei der DBA im Review-Pfad liegt. Die in Teil 2 neu formulierte Praxis #1 hat dies asynchron gestaltet. Auf Teamebene, wenn Agenten im Spiel sind, ist dieses asynchrone Review genau das, was die Fehler abfängt, die bei den Tests durchgerutscht sind.

Der SCM-Workflow ist das tragende Element. Im Lakebase App Dev Kit, Source-Control-Management deckt mehr ab als nur den Code-Branch: Es umfasst das paarweise Branching (der Code-Branch und der Lakebase-Branch werden als eine Einheit verwaltet, wie in Teil 1 vorgestellt). Dieses paarweise Branching, das als Feature im gemeinsamen Substrat des Lakebase App Dev Kit bereitgestellt wird, erzwingt gemeinsame Leitplanken wie Merges, die der Hierarchie widersprechen, die Migration, die mit dem Branch wandert, die CI-Gates und den Merge, der die Migration auf das übergeordnete Tier anwendet. Das Dev-Kit liefert diesen SCM-Workflow als ausführbare Zustandsmaschine aus.

Abb. 4 oben beschreibt die fünf Zustände während der Entwicklung: scaffold-complete, feature-claimed, pr-ready, ci-green, merged. Jeder Übergang zwischen verschiedenen Zuständen wird durch einen CLI-Befehl gesteuert (lakebase-scm-claim-feature-branch, lakebase-scm-prepare-pr, lakebase-scm-wait-ci, lakebase-scm-merge). Jeder CLI-Befehl validiert Vorbedingungen, bevor er ausgeführt wird, führt den Übergang durch und schreibt den neuen Zustand in .lakebase/workflow-state.json (eine schema-validierte Gate-Oberfläche). Ein fehlgeschlagenes Gate hinterlässt die Maschine in einem Zustand, der auf den vorherigen Zustand zurückgesetzt werden kann. Die Gates sind blockierend, nicht nur beratend.

Agenten rufen diese CLIs auf; sie können keinen parallelen Pfad erfinden. Das Substrat weigert sich, die Zustandsmaschine bei einer verletzten Vorbedingung weiterzuschalten: Ein Feature-Branch, der dem falschen Tier zugeordnet ist, wird abgelehnt; ein Versuch zu mergen, bevor CI grün ist, wird verweigert; eine inkonsistente Zustandsdatei blockiert das nächste Gate. Die Übergabeverträge liegen in der Verantwortung der Scrum-Master-Rolle; das Substrat erzwingt sie. Strukturelle Entscheidungen (die Tier-Hierarchie, das Quell-Tier für ein Feature, der Promotion-Pfad) gehören dem Architekten oder Scrum-Master, werden aufgezeichnet und dann vom Substrat respektiert. Das Substrat erfindet niemals ein Tier oder ein übergeordnetes Element; es respektiert das, was deklariert wurde, und verweigert Übergänge, die dem widersprechen.

Dies ist das Framework, das mit der bisherigen Art und Weise bricht, wie Teams Agenten eingesetzt haben. Die naive Integration behandelt einen Agenten wie einen Senior Engineer in einem Chatfenster: Kontext bereitstellen, nach Ergebnissen fragen, iterieren. Das funktioniert auf der Ebene eines einzelnen Entwicklers, scheitert aber auf Teamebene, da der „Kontext“ des Agenten nicht überprüft, gesteuert oder reproduziert werden kann. Behandeln Sie den Agenten stattdessen wie einen Junior-Entwickler: Geben Sie ihm eine klar umrissene, dokumentierte Aufgabe innerhalb einer ausführbaren Zustandsmaschine, validieren Sie seine Ausgabe anhand eines Schemas, schalten Sie das Gate weiter und wiederholen Sie den Vorgang. Das Substrat erzwingt dies; die Workflow-Zustandsdatei ist die API.

Playbook-Einträge für Praktiken auf Teamebene

Teil 2 stellte die Praktiken #10 und #11 der Zukunftsweisenden Praktiken für 2026 vor.

Praxis #10: Governance einmal entworfen, pro Branch vererbt

Regel. Das Berechtigungsmodell, Unity Catalog-Richtlinien zur Verwaltung der Zugriffskontrolle und die Erfassung des Audit-Trails werden einmal auf dem Trunk entworfen und automatisch von jedem nachfolgenden Branch vererbt.

Warum ist dies jetzt eine dauerhafte Gewohnheit? Auf Teamebene muss Governance eine Aufgabe des DBA oder Plattform-Engineers sein, nicht eine Disziplin, an die sich ein Entwickler erinnern muss. Branches werden in Sekundenschnelle erstellt und gelöscht; eine manuelle Governance-Konfiguration pro Branch würde die durch das Branching erzielte Zeitersparnis wieder zunichtemachen.

Funktionsweise:

• Deklarieren Sie die Tier-Hierarchie: Welche langlebigen Branches existieren, wie ihre übergeordneten Verknüpfungen aussehen und welche Governance-Ausrichtung jedes Tier hat.
• Deklarieren Sie die Berechtigungsgrenzen: Wer kann Branches von welchem Tier erstellen, wer kann zwischen Tiers befördern (promoten), wer darf lesen vs. schreiben.
• Deklarieren Sie die Vererbung von Unity Catalog-Richtlinien: Maskierung, Zeilenfilter und welche Berechtigungen auf Spaltenebene standardmäßig vom übergeordneten Element vererbt werden; tierspezifische Ausnahmen werden einmal deklariert. Die automatische Weitergabe über alle Unity Catalog-Richtlinientypen hinweg wird derzeit finalisiert; entwerfen Sie das Framework für den Zielzustand.
• Deklarieren Sie die Erfassung des Audit-Trails: Jede Branch-Erstellung, jede Promotion, jede Migrationsanwendung und jedes Zugriffsmuster landet automatisch in abfragbaren Systemtabellen.
• Der DBA oder Plattform-Engineer setzt dies über Richtlinien durch. Ein Übergang, der dem deklarierten Modell widerspricht, wird verweigert.

Anti-Pattern. Konfiguration der Governance pro Branch zur Laufzeit. Der Sinn der einmaligen Deklaration besteht darin, dass das Framework auch dann greift, wenn Branches schneller erstellt werden, als ein Mensch sie überprüfen kann. Eine manuelle Konfiguration pro Branch führt genau den Engpass wieder ein, den das Branching gerade beseitigt hat.

Wo Jens Team ansetzt. Der Plattform-Engineer oder DBA von Jen hat die Tier-Hierarchie bei der Projekterstellung definiert. Jeder Branch, den Jen, ihre Teammitglieder oder die Agents des Teams erstellen, erbt die deklarierte Maskierung, die Berechtigungen und die Audit-Konfiguration. Wenn das Team ein neues Tier hinzufügt, erfasst das Framework die neue Parent-Verknüpfung; laufende Features behalten ihren ursprünglichen Parent (keine nachträgliche Neuzuordnung); neue Features forken vom neuen Einstiegs-Tier.

Praxis #11: Agent als Anwender mit derselben Branching-Funktion

Regel. Agents agieren innerhalb der ausführbaren State Machine des SCM-Workflows: fünf Zustände, blockierende Gates dazwischen, schema-validierte Zustandsdateien. Für Jen und den Agent gelten dieselben Workflow-Regeln; ein gemeinsames Substrat setzt diese unabhängig davon durch, wer gerade agiert.

Warum ist das jetzt eine dauerhafte Gewohnheit? Die Erstellung von Branches ist eine Metadaten-Operation, sodass ein durch Agents getriebenes Volumen machbar ist. Das für die Nutzung durch Agents entwickelte Substrat kann Übergänge ablehnen, die der deklarierten Tier-Hierarchie oder dem erfassten Gate-Zustand widersprechen. Es gibt keinen Chatfenster-Kontext, auf den man zurückgreifen könnte; nur das Artefakt auf dem Datenträger (workflow-state.json) überschreitet die Grenze zwischen Gate-Übergängen.

Funktionsweise:

• Die SCM-State-Machine hat fünf Zustände: scaffold-complete, feature-claimed, pr-ready, ci-green, merged. Jeder Übergang wird durch ein CLI gesteuert; jedes CLI validiert Vorbedingungen, bevor es aktiv wird.
• Die Gate-Oberfläche ist .lakebase/workflow-state.json, validiert gegen scm-workflow-state.schema.json. Jeder Übergang schreibt den neuen Zustand und die Invarianten, die das nächste Gate benötigt.
• Strukturelle Entscheidungen (Tier-Hierarchie, Quell-Tier pro Feature, Promotion-Pfad, Übergabe-Verträge) gehören zu Rollen (Architekt oder Scrum-Master), werden erfasst und anschließend vom Substrat erzwungen.
• Agents rufen die CLIs auf. Das Substrat setzt die Regeln durch; Agents können diese nicht umgehen. Ein fehlgeschlagenes Gate hinterlässt die State Machine in einem Zustand, der auf den vorherigen Zustand zurückgesetzt werden kann; der Agent versucht es nicht „in einer anderen Form erneut“.
• Die CI-Gates, die innerhalb von pr-ready bis ci-green ausgeführt werden, testen echtes Postgres auf einem Branch, wobei der Schema-Diff im PR gepostet wird. Der tatsächliche Datenbankzustand ist das, woran die Arbeit des Agents gemessen wird.

Anti-Pattern. Einen Agent wie einen Senior Engineer in einem Chatfenster zu behandeln, indem man „den Kontext ausgibt und nach dem Output fragt“, funktioniert auf der Ebene einzelner Entwickler, scheitert jedoch auf Teamebene, da der „Kontext“ nicht überprüft, gesteuert oder reproduziert werden kann. Nutzen Sie stattdessen das Modell „Artefakt-als-API“: Agents LESEN workflow-state.json und die dokumentierten Inputs für ihre Phase; sie SCHREIBEN die dokumentierten Outputs; die Validatoren prüfen; das nächste Gate wird nur ausgelöst, wenn der Vertrag eingehalten wird.

Wo Jens Team ansetzt. Jeder Agent in Jens Team agiert innerhalb derselben State Machine mit fünf Zuständen wie Jen und ihre Teammitglieder. Die Rolle des Scrum-Masters besitzt die Übergabe-Verträge; das Substrat lehnt Übergänge ab, die diese nicht erfüllen. Ein Agent kann kein Feature bereitstellen, das vom falschen Tier geforkt wurde; ein Agent kann nicht mergen, bevor CI grün ist; ein Agent kann das Schema-Diff-Artefakt nicht umgehen. Das Framework greift unabhängig davon, wer oder was die Aktion initiiert hat.

TDD als optionale, darüber liegende Ebene

Praxis #11 etabliert den SCM-Workflow als Baseline: Jeder Nutzer des Kits folgt ihm, Agents und Menschen gleichermaßen. TDD ist eine separate Überlegung, die sich als zusätzliche Ebene über diese Baseline legt, für Teams, die eine Test-First-Disziplin wünschen. Es ist optional; die SCM-Gates sind unabhängig vom Pfad obligatorisch.

Warum Tests wichtig sind, noch vor TDD: Wenn Agents Code schreiben, sind Tests die einzige Durchsetzungsmethode, die skaliert. Kent Beck nannte in seinem Interview mit dem Pragmatic Engineer im Jahr 2026 das Fehlermuster öffentlich: Er hat Mühe, KI-Agents davon abzuhalten, Tests zu löschen, damit sie bestanden werden. Der grüne Balken ist leicht zu erreichen, wenn nichts in der Schleife den Agent dazu zwingt, sich mit der realen Struktur des Systems auseinanderzusetzen. Mocks machen dies trivial. In-Memory-Ersatzlösungen ebenfalls.

Branching sorgt für einen ehrlichen grünen Balken auf der Datenebene. Der Agent testet gegen eine echte Datenbank auf einem echten Branch; die Schema-Constraints weisen Zeileneinfügungen ab, die nicht übereinstimmen, Fremdschlüssel weisen verwaiste Datensätze ab, die reale Datenstruktur deckt Annahmen auf, die der Mock stillschweigend geschluckt hätte, und der Agent kann keine Tabellen löschen. Die Kosten für das Vortäuschen von Compliance steigen mit diesen Guardrails.

Aber das Substrat ist notwendig, aber nicht ausreichend. Tests müssen irgendwo herkommen. Wenn der Agent sie schreibt, kann der Agent sie auch löschen. Dies ist die Lücke, die TDD schließt.

Der TDD-Workflow liegt über dem SCM-Workflow. Er wird zwischen den SCM-Zuständen feature-claimed und pr-ready ausgelöst; er greift für Branch-Operationen auf SCM zu (Zyklus-Experiment-Branches nutzen im Hintergrund das SCM-Primitiv); er ruft SCM nicht in umgekehrter Richtung auf. Die Abhängigkeit ist einseitig. Teams, die die TDD-Ebene nicht nutzen möchten, können Features durch direktes Bearbeiten auf dem Feature-Branch bereitstellen und dennoch jedes SCM-Gate erfüllen.

Das Lakebase App Dev Kit liefert den TDD-Workflow als zweite State Machine mit eigenen rollenspezifischen Agents und Gate-Validatoren aus:

• Spec-Author verwandelt eine Anforderungsbeschreibung in ein strukturiertes Feature-Artefakt, das schema-validiert ist.
• Architect-Reviewer ordnet die nicht-funktionalen Anforderungen und Architekturprinzipien des Features Architekturentscheidungen zu, ausgegeben als architecture.json plus Fließtext.
• Test-Stratege erstellt die Testliste und Szenarien pro Akzeptanzkriterium, ausgegeben als test-list.json plus gerendertes Markdown. Jede NFR hat mindestens ein Akzeptanzkriterium (AC); jede AC hat ein Szenario.
• Scrum-Master orchestriert die Build-Zyklen. Jeder Zyklus forkt einen Experiment-Branch (unter Nutzung des darunter liegenden SCM-Substrats), führt einen Driver-Agent aus, um die nächste AC zu implementieren, und führt einen Navigator-Agent aus, um das Ergebnis zu überprüfen und zu validieren.
• Driver und Navigator sind die Test- und Code-Schreiber der inneren Schleife, gepaart, RED-GREEN-REFACTOR.

Jede Rolle hat dokumentierte Inputs und Outputs, die gegen ein Schema validiert werden. Jeder Agent erhält nur seine dokumentierten Inputs; Outputs werden validiert, bevor die nächste Rolle ausgeführt wird. Das Artefakt ist die API zwischen den Rollen; das Schema ist die Typprüfung. Ein fehlendes Artefakt wird wie ein fehlgeschlagenes Gate behandelt. Ein fehlerhaftes Artefakt wird wie ein fehlendes behandelt. Die TDD-Ebene übernimmt dasselbe „Artefakt-als-API“-Modell, das Praxis #11 für SCM etabliert hat.

Die TDD-Ebene befindet sich im Begleitmaterial: Lakebase App Dev Kit (Open-Source, mit einem begleitenden E-Book für menschliche Anwender). Die SCM- und TDD-State-Machines, die rollenspezifischen Agent-Verträge, die Artefakt-Konformitätsprüfungen und die Gate-Validatoren werden alle als CLIs ausgeliefert, die jeder Orchestrator (das Kit, die IDE-Erweiterung, ein CI-Job, eine menschliche Shell-Sitzung) aufrufen kann.

Die Kurzfassung: SCM ist die Baseline (Praxis #11). TDD ist eine darüber liegende Ebene. Branching sorgt für ehrliche Tests; TDD sorgt dafür, dass Tests an erster Stelle stehen; das Kit macht beide Workflows ausführbar.

Was Jens Team zeigt

Teil 1 führte Jen durch ein Feature: Sie verknüpfte einen Code-Branch mit einem Lakebase-Branch, führte in Sekundenschnelle eine echte Migration für produktionsnahe Daten aus, testete ohne Mocks, öffnete einen PR mit dem inline geposteten Schema-Diff zur Überprüfung und führte den Merge durch, wobei die Migration angewendet und die flüchtigen Branches bereinigt wurden. Datenbankänderungen wurden Teil der normalen Entwicklung.

Teil 2 stellte das Playbook vor: die sieben Praktiken aus dem Jahr 2003, die Einschränkungen, die fünf davon bis 2026 reine Theorie bleiben ließen, dieselben sieben neu aufgelegt, sobald das Branching eingeführt wurde, plus zwei neue Praktiken, die die Technologie für den einzelnen Entwickler ermöglicht. Neun Praktiken im Alltag, zwei weitere auf Teamebene.

Teil 3 brachte das Playbook auf Teamebene. Er definierte die Tier-Topologie und beschrieb, wie langlebige Branches in einem Lakebase-Parent liegen, wie das Berechtigungsmodell zum Design-Artefakt des Plattform-Engineers wird – einmal deklariert und vom Substrat erzwungen (Praktik #10). Wie sich die Rolle des DBA zum Plattform-Architekten weiterentwickelt, mit fünf Argumenten zur Unterstützung der Personalplanung von 2003. Agenten steigen mit derselben Funktion in den Workflow ein, und zwar innerhalb der ausführbaren Zustandsmaschine des SCM-Workflows, wobei das Substrat die Gates unabhängig davon erzwingt, wer oder was agiert (Praktik #11). TDD ist eine optionale, darüber gelagerte Ebene: eine Tests-First-Disziplin mit dedizierten Rollen, Gates und Artefakt-Verträgen für Teams, die dies wünschen.

Der Companion: Plugin-Walkthrough behandelt die Lakebase SCM Extension für VS Code und Cursor von Anfang bis Ende.

Der Companion: Lakebase App Dev Kit, zusammen mit einem begleitenden E-Book für menschliche Anwender, deckt den oben genannten TDD-Workflow ab: die SCM- und TDD-Zustandsmaschinen, die rollenspezifischen Agenten, die Gate-Validatoren und die Artefakt-Verträge, die den sicheren Einsatz von Agenten im Team ermöglichen.

Die Methodik war seit zwanzig Jahren klar. Die technische Machbarkeit wurde 2026 erreicht. Das Playbook für menschliche und Agenten-Anwender ist nun einsatzbereit. Jens Team besteht aus fünfzig Entwicklern und einer Flotte von Agenten; der Workflow ist derselbe.

Fazit: Die Möglichkeit des Datenbank-Branchings bietet dem Entwicklungsteam nun immense Flexibilität bei der Bereitstellung von Datenbanken, der Erstellung von Tests für echte Schemata, der Ausführung von CI für jede PR-Erstellung für eine eigene Datenbank und der Ermöglichung der Arbeit von Agenten auf diese Weise – und das alles unter dem Governance-Framework von Unity Catalog, das die Richtlinien durchsetzt.

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