Wir stellen Consort vor: Testgetriebene Entwicklung auf einer verzweigten Datenbank

Seit 25 Jahren entwickle ich Software nach den Praktiken, mit denen ich aufgewachsen bin: Kent Becks TDD, Martin Fowlers Refactoring, Uncle Bobs Clean Code, Jez Humbles und Dave Farleys Continuous Delivery, Pramod Sadalages und Scott Amblers Evolutionary Database Design.

Mit modernen Softwareentwicklungspraktiken kann Code verzweigt werden, Umgebungen sind containerisiert und Infrastruktur wird zu Code. Aber ein Teil des Stacks hat nie mitgespielt: die Datenbank. Sie stand da wie ein starrer Monolith, und wir haben deshalb viele Workarounds akzeptiert, wie Mocks anstelle des Originals, eine gemeinsame Staging-Umgebung und Schemaänderungen, die wie eine vorsichtige Zeremonie abliefen.

Ich spreche schon seit einer Weile mit Software-Entwicklungsteams über Lakebase Postgres und darüber, wie es unsere bisherige Arbeitsweise verändert. Sie haben mich vielleicht schon sagen hören: Erstellen Sie Branches für Ihre Datenbank wie für Ihren Code. Aber was bedeutet das in der Praxis und wie wende ich es an?

Was sich durch Datenbank-Branching ändert

Integrationstests kehren in den Inner Loop zurück

Das Testen gegen eine echte Datenbank war früher eine Angelegenheit des Outer Loops. Eine Datenbank bereitzustellen, sie mit Schema und Daten zu befüllen, das Schema zu versionieren und dies pro Unit-Test zu tun, war zu aufwendig, also habe ich es gelassen. Niemand hat das getan. Stattdessen haben wir Unit-Tests gegen Mock-Objekte geschrieben – nicht, weil Mocks gut waren, sondern weil eine echte Datenbank im Inner Loop unerreichbar war. Und wir wissen, dass Mocks im Laufe der Zeit abweichen; sie passen nicht mehr zum tatsächlichen Verhalten der Datenbank, und je mehr man sie pflegt, desto weniger echtes Verhalten verifizieren sie.

Copy-on-Write-Branching macht Mocks überflüssig. Sie erstellen in nahezu konstanter Zeit einen isolierten Branch der echten Datenbank, unabhängig von der Datengröße. Der erste Test, den ich im TDD-Stil schreibe, läuft gegen einen Live-Branch mit echten Daten, nicht gegen einen Fake. Ich kann destruktive Tests ausführen, alles zerstören, mein Schema zerschießen und komme dem restlichen Team nie in die Quere. Es ist mein Branch. Wenn ich fertig bin, werfe ich ihn weg.

Code und Schema werden als Einheit ausgeliefert

Da das Schema nun als versionierte Migrationen (Alembic, Flyway oder Knex, je nach Stack) übertragen wird, bewegen sich eine Schemaänderung und der Code, von dem sie abhängt, zusammen als eine einzige Einheit. Sie führen das Schema zusammen (nicht die Daten), und der Code passt sich an. Zwei Entwickler, denen ich dies in verschiedenen Teams gezeigt habe, kamen auf denselben Begriff dafür: Data CD.

Der Produktionsausfall um 2 Uhr morgens wird verhindert, bevor er passiert

Wenn in der Produktion etwas schiefgeht, ist es meistens um 2 Uhr morgens, und man muss mühsam rekonstruieren, was sich geändert hat. Branching dreht den Spieß um. Bei jedem Pull Request und erneut beim Merge erstellen Sie einen frischen Datenbank-Branch aus der Zielumgebung, führen die Migrationen und die gesamte Testsuite dagegen aus und finden die Regression oder den Konflikt, bevor die Bereitstellung erfolgt. Die Schemaänderung befindet sich als Migration im Pull Request, sodass Ihr DBA sie dort als Code-Owner überprüft und nicht als Ticket in einer nachgelagerten Warteschlange.

Die Freigabe einer Schemaänderung war früher ein hochriskantes Unterfangen. Jetzt erstellen Sie einen Branch von der Produktionsumgebung, wenden die Änderung an, testen sie isoliert und geben sie frei. Dasselbe auf einem standardmäßigen Cloud-Postgres-Setup zu tun, erfordert einen Haufen fragiler DevOps-Skripte und verschwendet wertvolle Zeit.

Nichts davon ist eine Datenbankfunktion, die man einfach einschaltet. Es ist eine Verschiebung des Zeitpunkts, wann die schwierigen Tests stattfinden – ganz nach links (Shift-Left), direkt in die Schleife, in der Sie tatsächlich den Code schreiben.

Ein agentisches Entwicklungs-Framework mit Datenbank-Branching

Jetzt, da die Infrastruktur für das Branching vorhanden ist, fehlte in der Diskussion noch etwas, das sie in einer echten Entwicklungsschleife nutzbar macht. Aus diesem Grund habe ich Consort entwickelt.

Consort ist ein Open-Source-Framework für agentische Entwicklung, das Lakebase-Branching als Grundlage für seinen testgetriebenen Build nutzt. Wenn Sie Scrum kennen, liegt die Idee im Namen. Jede Rolle im Team (Product Owner, Spec-Autor, Architect-Reviewer, DBA, Test-Stratege und ein Navigator/Driver-Paar) wird zu einem Agenten. Sie agieren zusammen, geführt von einem Conductor, und treten letztendlich als Consort (Ensemble) auf.

Die Arbeit läuft in zwei Bahnen ab: einer Spec-First-Designbahn, in der die Absicht vereinbart und eingefroren wird, und einer Build-Bahn, die den vollständigen Red/Green/Refactor-Zyklus auf einem Live-Branch der echten Datenbank ausführt. Einige Komponenten sorgen dafür, dass alles zusammenhält, wenn ein Agent den Code schreibt.

• Der Agent erhält einen echten Prüfstein. Gibt man einem Agenten etwas Konkretes, löst er das Problem, weil er erkennt, wenn der Code nicht funktioniert. Gibt man ihm einen hermetischen, gemockten Test, liefert er gerne etwas, das so aussieht, als würde es funktionieren, aber in dem Moment abstürzt, in dem man es auf einer echten Datenbank ausführt. Ein Live-Branch mit echten Daten ist dieser konkrete Prüfstein – der Agent kann sich nicht an einer Datenbank vorbeimogeln, die tatsächlich existiert.
• Der Driver kann die Spielregeln nicht nachträglich ändern. Die Rolle, die den Code schreibt, kann einen Test nicht ändern, damit er besteht. Die einzige Ausnahme ist eine echte Ablösung durch eine spätere Story, die einen alten Test legitimerweise hinfällig macht. „Grün“ bedeutet, dass der Test auf dem echten Datenbank-Branch gelaufen ist und bestanden hat, und nicht, weil der Agent das behauptet hat.
• Der Conductor ist Code, kein Agent. Die Rolle, die ein Team als Scrum Master bezeichnet, wird zu einer deterministischen Zustandsmaschine. Sie leitet die Arbeit weiter, verwaltet die Freigabeschritte durch Menschen und leitet bei Konflikten an die verantwortliche Rolle zurück. So kann der Prozess, der den Zyklus steuert, nicht aus dem Takt gebracht werden oder den Faden verlieren.
• Es verliert das Ziel nicht aus den Augen. Die häufigste Beschwerde, die ich über andere Frameworks höre, ist, dass der Agent nach ein paar Tagen das Ziel aus den Augen verliert, man frustriert ist und neu startet. Consort speichert die Artefakte jedes Features in einer dedizierten Verzeichnisstruktur, die von den Agenten als Vertrag zwischen den Rollen gelesen wird. Es ist derselbe Übergabeprozess, den auch ein echtes Team durchläuft: Jeder Spezialist prüft die Arbeit, fügt seine Anmerkungen hinzu und gibt sie an den nächsten weiter.

Als Optimierungsstrategie (damit Ihre Agenten nicht zu Beginn jeder Runde alles neu scannen müssen) stellt Consort jedem Agenten ein eingegrenztes Kontextpaket bereit – die genauen Tests, die bestanden werden müssen, die Designanforderungen und den Ort, an dem diese Tests liegen –, anstatt ihn auf die gesamte Codebasis loszulassen. Unbeschränkter Zugriff führt dazu, dass Agenten abdriften und Ewigkeiten damit verbringen, den Code zu durchforsten, um herauszufinden, was zu tun ist und wohin es gehört, bis sie schließlich vergessen, was DRY bedeutet.

Der Architekt prüft die Spezifikation, bevor Code geschrieben wird, und plant das gewünschte Design ein, einschließlich übergreifender Anforderungen, Schichtenarchitektur und Mustern wie DRY, SRP und SOLID. Dieses vorausschauende Design verhindert, dass am Ende alles in einer einzigen Datei landet. Und wenn Sie experimentieren möchten, Consort führt parallele Experimente für eine Story aus – jedes auf einem eigenen Datenbank-Branch und Worktree, völlig isoliert –, sodass Sie mehr als einen Ansatz ausprobieren und das bessere Experiment behalten können. Wenn ich dies anderen Entwicklern gezeigt habe, erkannten sie es meist sofort als das, was sie selbst zu bauen versucht hatten.

Sie können das Ganze mitverfolgen und die Richtung steuern. Ein VS Code-Plugin zeigt Ihre gekoppelten Git- und Lakebase-Branches über alle Ebenen hinweg an, mit Code- und Schemaänderungen in einer einzigen Diff-Ansicht. Ein Observability-Dashboard zeigt jede Runde live: jede Rolle, ihren Prompt und die Artefakte, die sie für die nächste Rolle zur Nutzung bereitstellt. Und an jedem Freigabepunkt prüfen Sie die funktionierende Software selbst, während sie auf ihrem eigenen Branch läuft, bevor Sie sie für den nächsten Schritt freigeben.

Was Consort ist (und was nicht)

Consort ist Open Source und wird von der Community unterstützt. Es ist ein Projekt, das Sie übernehmen, ausführen und empfehlen können, mit einem eigenen Lebenszyklus. Es ist kein integriertes Plattform-Feature mit einem SLA.

Sie müssen Ihren Stack nicht umbauen, um es zu nutzen. Lakebase ist Postgres, sodass Ihre fertige App darauf läuft, ohne dass ein Branching-Workflow erforderlich ist. Das gekoppelte Git- und Lakebase-Branching ist etwas, das Sie während der Entwicklung tun.

25 Jahre lang war die Datenbank der einzige Teil unseres Stacks, der nicht verzweigt werden konnte. Jetzt kann sie es. Das ist es, was sich ändert, und deshalb habe ich Consort entwickelt.

Probieren Sie es selbst aus

Sie benötigen lediglich Lakebase. Holen Sie es sich in der Free Edition.

Der Rest des Stacks ist offen – Java, Python, oder Node – und es läuft auf Claude und bietet ein passendes VS Code-Plugin.

Wenn Sie bereit sind, sind es nur drei Befehle:

/consort:start führt Sie in ein Projekt ein. Beginnen Sie mit dem StockFlow-Beispiel. Es startet mit drei Dateien, und Sie können zusehen, wie es von dort aus zu einer vollständigen Codebasis heranwächst.

Eine (R)Evolution des Softwarebaus

Wenn diese Arbeit Sie inspiriert und Sie sie verbessern möchten: Ich suche nach weiteren Mitwirkenden und Code-Ownern. Wenn Sie mitmachen oder einfach nur sehen möchten, wie das Innenleben funktioniert, gibt es ein Paper auf arXiv: https://arxiv.org/abs/2609.09671 oder besuchen Sie das Repository: https://github.com/databricks-solutions/consort

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