実際のブランチングデータベース上でのテスト駆動開発のために、Databricks Field Engineeringによって開発されたオープンソースのエージェント型フレームワーク。
によって Kevin Hartman による投稿
私は25年間、自分が慣れ親しんできたプラクティスに基づいてソフトウェアを構築してきました。Kent BeckのTDD、Martin Fowlerのリファクタリング、Uncle Bobのクリーンコード、Jez HumbleとDave Farleyの継続的デリバリー（Continuous Delivery）、Pramod SadalageとScott Amblerの進化的データベースデザインなどです。
現代のソフトウェア開発プラクティスでは、コードはブランチ化でき、環境はコンテナ化され、インフラストラクチャはコードになります。しかし、スタックの1つの部分だけがこれに追従できませんでした。それがデータベースです。データベースは硬直したモノリスとしてそこに居座り、そのために私たちは、本物の代わりにモックを使用したり、ステージング環境を共有したり、スキーマ変更を慎重な儀式のように実行したりといった、多くの回避策を受け入れてきました。
私はしばらくの間、ソフトウェア開発チームとLakebase Postgresについて、そしてそれがこれまでのやり方をどのように変えるかについて話してきました。私が「コードをブランチ化するように、データベースもブランチ化しよう」と言うのを聞いたことがあるかもしれません。しかし、それは実際にはどういう意味で、どのように適用すればよいのでしょうか？
インテグレーションテストがインナーループに戻ってくる
かつて、本物のデータベースに対するテストはアウターループ（開発サイクルの外側）の課題でした。データベースを立ち上げ、スキーマとデータを投入し、スキーマ のバージョン管理を行い、それをユニットテストごとに実行することはコストがかかりすぎたため、私は行いませんでした。誰も行っていませんでした。代わりにモックオブジェクトに対してユニットテストを書いていましたが、それはモックが優れていたからではなく、インナーループ（開発サイクルの内側）で本物のデータベースを使用することが不可能だったからです。そして、モックは時間の経過とともに乖離（ドリフト）していくことが分かっています。データベースの実際の挙動とズレが生じ、メンテナンスすればするほど、検証できる実際の挙動は少なくなっていきます。
コピーオンライト（Copy-on-write）のブランチ化により、モックが存在する理由はなくなります。データのサイズに関係なく、ほぼ一定の時間で本物のデータベースの隔離されたブランチを作成できます。TDDスタイルで最初に書くテストは、偽物ではなく、本物のデータのライブブランチに対して実行されます。破壊的なテストを実行したり、すべてを台無しにしたり、スキーマをめちゃくちゃにしたりしても、チームの他のメンバーが使っている環境には一切影響を与えません。これは私自身のブランチだからです。終わったら、破棄すればよいのです。
コードとスキーマを一体として提供する
スキーマがバージョン管理されたマイグレーション（スタックに応じて Alembic、Flyway、Knex など）として扱われるようになったため、スキーマの変更とそれが依存するコードは、1つのユニットとして一緒に移動します。スキーマをマージすると（データではなく）、コードがそれに同期します。私がこれを異なるチームの2人のエンジニアに見せたところ、2人とも同じ表現にたどり着きました。それが「Data CD」です。
午前2時の本番環境の障害を、発生前に防ぐ
本番環境で何かが壊れるのは、大抵は午前2時であり、何が変更されたかをリバースエンジニアリングすることになります。ブランチ化はこのタイミングを逆転させます。すべてのプルリクエスト（PR）時、そしてマージ時に、ターゲット環境から新しいデータベースブランチを作成し、それに対してマイグレーションとフルテストスイートを実行して、デプロイ前にデグレード（リグレッション）や競合を発見します。スキーマ変更はマイグレーションとしてプルリクエストに含まれるため、DBAは下流のキューにあるチケットとしてではなく、コードオーナーとしてそこでレビューを行います。
かつてスキーマ変更を本番環境に適用（プロモート）することは、リスクの高い儀式でした。今では、本番環境（prod）をブランチ化し、変更を適用し、隔離された環境でテストしてからプロモートできます。バニラなクラウド Postgres のセットアップで同じことを行おうとすると、壊れやすい DevOps スクリプトが大量に必要になり、貴重な人の時間が無駄になります。
これは、スイッチをオンにするだけで使えるデータベースの機能ではありません。これは、困難なテストを実行するタイミングを、実際にコードを書いているループの極限まで左側（シフトレフト）に移動させるという変革なのです。
ブランチングのインフラストラクチャが整った 今、議論に欠けていたのは、それを実際の開発ループで機能させるものでした。だからこそ、私は Consort を構築しました。
Consort は、Lakebase のブランチングをテスト駆動型ビルドの基盤として使用する、オープンソースのエージェンティック開発フレームワークです。スクラムをご存知なら、そのアイデアは名前に表れています。チームの各役割（プロダクトオーナー、仕様作成者、アーキテクトレビューアー、DBA、テストストラテジスト、ナビゲーター／ドライバーのペア）がエージェントになります。彼らはコンダクター（指揮者）に率いられて共に演奏し、最終的にはコンソート（合奏団）として機能します。
作業は2つのレーンで進行します。意図が合意され凍結される「仕様ファーストの設計レーン」と、本物のデータベースのライブブランチに対して完全なレッド／グリーン／リファクタリングのサイクルを実行する「ビルドレーン」です。エージェントがコードを書く際に、全体をまとめるいくつかのコンポーネントがあります。
最適化戦略として（エージェントが各ターンの開始時にすべてを再スキャンす るのを防ぐため）、Consort はコードベース全体にエージェントを放つのではなく、スコープを絞ったコンテキストパッケージ、パスすべき正確なテスト、設計要件、およびそれらのテストの場所を各エージェントに提供します。スコープのないアクセスは、エージェントのドリフトを引き起こし、何をすべきか、どこに配置すべきかを理解しようとコードをいじくり回すことに膨大な時間を費やし、最終的には DRY の意味すら忘れてしまう原因になります。
アーキテクトはコードが書かれる前に仕様をレビューし、非機能要件、レイヤリング、DRY、SRP、SOLID などのパターンを含む、重視する設計を組み込みます。この事前の設計があるからこそ、すべてが1つのファイルにまとまってしまうような事態を防ぐことができます。また、探索を行いたい場合、Consort はストーリーに対して並行して実験を実行し、それぞれ独自のデータベースブランチとワークツリーで完全に隔離されるため、複数のアプローチを試してより優れた実験結果を採用できます。これを他のエンジニアに見せたとき、彼らは自分たちが構築しようとしていたものそのものだと、すぐに気づく傾向があります。
これらすべてを監視し、方向性をコントロールできます。VS Code プラグインは、ペアリングされた Git と Lakebase のブランチをティアをまたいで表示し、コードとスキーマの変更を単一の diff ビューで確認できます。オブザーバビリティダッシュボードは、各ターンをライブで表示します。すべての役割、そのプロンプト、そして次の役割が消費するために生成する成果物が表示されます。そして、各ゲートにおいて、動作するソフトウェアをご自身で検査し、独自のブランチに対して実行した上で、次のステップへの承認を行います。
Consort はオープンソースであり、コミュニティによってサポートされています。これは、独自のライフサイクルを持ち、採用、実行、推奨できるプロジェクトです。SLA が提供されるバンドルされたプラットフォーム機能ではありません。
これを使用するためにスタックを再構築する必要はありません。Lakebase は Postgres であるため、完成したアプリケーションはブランチングワークフローを必要とせずにその上で動作します。ペアリングされた Git と Lakebase のブランチングは、開発中に行うものです。
25年間、データベースは私たちのスタックの中でブランチ化できない唯一の部分でした。今ではそれが可能です。それが変化であり、私が Consort を構築した理由です。
必要なのは Lakebase だけです。Free Edition で入手してください。
スタックの残りの部分はオープン（Java、Python、Node）であり、Claude 上で動作し、VS Code プラグインが付属しています。
準備ができたら、3つのコマンドを実行するだけです。
/consort:start がプロジェクトへと案内します。まずは StockFlow の例から始めましょう。3つのファイルがシードされ、そこから完全なコードベースへと成長していく様子を確認できます。
この取り組みにインスピレーションを受け、さらに改善したいと思われる方は、コントリビューターやコードオーナーを募集しています。参加したい方、あるいは内部の仕組みを知りたい方は、arXiv の論文をご覧ください： https://arxiv.org/abs/2609.09671 または リポジトリにアクセスしてください： https://github.com/databricks-solutions/consort
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。