進化的データベース開発の実現：Lakebaseによるデータベースのブランチング（続き）
パート2：ジェンの新しいプレイブック
によって Pramod Sadalage 、 Kevin Hartman による投稿
このシリーズでは、20年後の「エボリューショナリー・データベース・デザイン（進化型データベース設計）」の手法を再考します。「コードとしてのデータベース変更（database-changes-as-code）」における最大の制約は、常に共有データベースリソースにありました。Databricks Lakebaseのコピーオンライト（copy-on-write）ブランチ機能により、テラバイト規模の本番データベースのブランチ作成が、作成時のストレージ消費ゼロ、わずか1秒のO(1)操作で可能になりました。これにより、プラクティス4（全員が専用のデータベースインスタンスを持つ）を単なる理想にとどめていた制約が解消されました。 本シリーズでは、この制約が解消されたときに何が変わるのかを著者が解説します。変わるのは手法そのものではなく（手法は維持されます）、初めて実現可能になるプラクティス、自動化されるチーム規模のガバナンス、DBAの役割の進化、そしてエージェントが人間の開発者と共有する新たな機能です。
ジェン（Jen）は、Evolutionary Database Designに登場する開発者のキャラクターです。そのエッセイの中で、彼女は日常的なユーザーストーリーとしてデータベースのリファクタリングを実施し、inventory_code フィールドを location_code、batch_number、および serial_number に分割しました。これは、DBAと開発者が連携でき、スキーマを少しずつ進化させることができ、マイグレーションによって変更を安全に適用できることを示しています。
本シリーズは、20年後のジェンのストーリーから始まります。彼女が実践する手法は、2003年当時と同じものです。新しいのは、lakebaseアーキテクチャによって実現された、ワークフローの基盤となる技術的機能です。それはコピーオンライトによるデータベースブランチ機能であり、彼女がこれまで読んできたプラクティスを本番規模で実用的なものにします。全3パー トからなるこのシリーズを通じて、彼女は3つの異なるスコープ（パート1：彼女の1日、パート2：彼女の新しいプレイブック、パート3：彼女のチーム）における「同じジェン」として登場します。
パート1では、ジェンがある1つの機能開発を進める様子を追いました。彼女が従ったプラクティスは、2003年のエッセイEvolutionary Database Designで説明され、2006年の書籍Refactoring Databasesで拡張され、2010年の書籍Continuous Delivery（第12章）でCI/CDパイプラインに組み込まれたものです。
オリジナルの7つのプラクティス
2003年のエッセイでは、7つのプラクティスが挙げられていました。そのうち5つは、2026年まで適用に制限がありました。
- DBAが開発者と密接に連携する。
- すべてのデータベースアーティファクトをアプリケーションコードとともにバージョン管理する。
- すべてのデータベース変更をマイグレーションにする。
- 全員が専用のデータベースインスタンスを持つ。
- 開発者がデータベース変更を継続的に統合する。
- すべてのデータベース変更をデータベースリファクタリングにする。
- 開発者がオンデマンドでデータベースを更新できるようにする。
適用における制限
- プラクティス1（DBAとの連携）： スキーマ変更に不備があると本番規模の影響が及ぶため、DBAによるレビューは同期型かつゲートキーパー的なままでした。連携はDBAのスケジュールに制約されていました。
- プラクティス4（全員が専用のデータベースインスタンスを持つ）： ライセンスコスト、インフラコスト、DBAの工数などの問題から、ほとんどのチームにとってこれは理想にすぎませんでした。多くのチームは共有の開発データベースに逆戻りし、競合を受け入れていました。
- プラクティス5（データベース変更の継続的統合）： 2010年のContinuous Deliveryの潮流によりマイグレーションがパイプラインに組み込まれましたが、パイプラインは共有のターゲットデータベースに対してマイグレーションを実行していました。パイプラインごとの分離が欠けていました。
- プラクティス6（すべてのデータベース変更をリファクタリングにする）： 各リファクタリングを適用するには、PR単位で利用できる練習用スペース（テストデータベース）が必要でしたが、ほとんどのチームにはそれがありませんでした。
- プラクティス7（開発者がオンデマンドで更新する）： 開発者はオンデマンドで共有環境に対してマイグレーションを実行できましたが、実験が他者に影響を与えるため、安全に実験を行うことはできませんでした。
何が変わったのか
Databricks Lakebaseが導入した技術により、上記のプラクティスを実装する上での障害が取り除かれます。Databricks Lakebaseは、他のDatabricksレイクハウスが稼働しているのと同じオブジェクトストレージレイヤー（データレイク）を使用する、マネージドなPostgresデータベースです。データベースのデータは、共有の耐久性に優れたストレージ（実質的にはS3バケット）に保存され、Postgresエンジンはその上の独立したコンピュートレイヤーとして動作します。コンピュートとストレージは個別にスケールします。エンジンは、負荷に応じてスケールアップし、トラフィックが減少するとスケールダウンし、アイドル時にはゼロまでスケールダウンできます。LakebaseはUnity Catalogと統合されており、複数の環境にわたる統一されたガバナンスを可能にします。
この分離されたアーキテクチャによって、規模に応じた実用性を獲得したのが、コピーオンライトによるデータベースブランチ機能です。ブランチを作成すると、分岐マーカーとともに、同じ共有ストレージを指す新しいポインタが作成されます。ブランチに書き込みが発生するまでは、すべてのページが親と共有されます。ブランチに書き込みが行われると、変更されたペー ジのみが分岐し、親は一切変更されません。ブランチ作成はメタデータ操作であり、データのコピーは不要なため、親のサイズに関係なく約1秒で完了します。ブランチは、変更されたページのデータのみを保持します。
ブランチ作成の技術的コストが内部のデータサイズから切り離されると、プラクティス4（全員が専用のデータベースインスタンスを持つ）の背景にあった制約が解消されます。開発者ごと、PRごと、実験ごとのブランチ作成が日常的なものになります。そのための補完的なレイヤーは不要になります。テストループからモックが排除され、テストごとのブランチ上の本物のPostgresに置き換えられます。共有のステージング環境が、スキーマ変更をテストする唯一の場所ではなくなります。インメモリデータベースの代替（H2、SQLite）は、ユニットテストレイヤーから不要になります。ローカルデータベースを実行するためにDockerベースのコンテナを作成するDevOpsの負担は不要になり、ブランチがセルフサービス化されるため、プロビジョニングのためのDBAのチケットキューは縮小します。
このテクノロジーこそが、手法の最適化を可能にし、2003年の最初の投稿の背景にあるプラクティスの目標を達成するものです。
2026年に向けた新たなプラクティス
Lakebaseのコピーオンライトによるデータベースブランチ機能は、従来のプラクティスにおける制限を取り除き、さらに詳しく説明すべき4つの追加プラクティスを可能にします。
- DBAが開発者と密接に連携する。すべてのPRにスキーマの差分 （diff）が投稿されるため、DBAは他のコードレビュー担当者と同様に非同期でレビューを行えます。プロビジョニングの負担がほぼゼロになるため、DBAにはレビューを行う余裕が生まれ、実装後にレビューするだけでなく、最初から開発者と協力してソリューションを構築することも可能になります。
- すべてのデータベースアーティファクトをアプリケーションコードとともにバージョン管理する。スキーマの差分、データベースマイグレーション、およびマイグレーションのテスト結果が、アーティファクトセットに加わります。
- すべてのデータベース変更をマイグレーションにする。さらに、新しい作成ルールとして「べき等性（idempotency）」が加わります。これにより、マージされたすべてのマイグレーションを、QA、ステージング、Productionなどの下流環境に自動的にデプロイできるようになります。
- 全員が専用のデータベースインスタンスを持つ。開発者ごと、PRごと、実験ごとの粒度で運用可能です。これにより、開発者は最初に動いた解決策だけで妥協するのではなく、複数のソリューションを実験できるようになります。この自由度により、本番規模に最適なソリューションが開発されるようになります。
- 開発者がデータベース変更を継続的に統合する。PR単位での運用が可能です。すべてのPRは、独自のブランチ上でCIを実行します。
CIでのワークフローの実行方法
Lakebaseが提供する機能によって最も改善される2つのプラクティスは、#4（全員が独自のデータベースインスタンスを持つ）と#5（開発者が継続的にデータベース変更を統合する）です。今や、全員がデータベースを持てるだけでなく、すべてのPRやブランチ、あるいはブランチごとに複数のデータベースを、ごくわずかなコストと時間で用意できます。この仕組みは、すべてのプロジェクトにスキャフォールディングできる2つのGitHub Actionsワークフローテンプレートを使用して自動化できます。
PRごとのブランチ作成。 pr.yml は pull_request: [opened, synchronize] でトリガーされ、PRのベースブランチからフォークされた ci-pr-<N> を作成します：
同じジョブがCIブランチに対して移行を適用し、実際のPostgresに対してアプリケーションのテストスイートを実行します。ワークフローの完全な例はこちらで確認できます： pr.yml
PRに投稿されたスキーマの差分。 同じ pr.yml ジョブが両方のブランチのスキーマをダンプし、差分をフォーマットして、PRコメントとして投稿します。これにより、DBAは他のコードレビュー担当者と同様に非同期でレビューを行うことができます（プラクティス#1、再キャスト）：
DBA、コードレビュー担当者、チーム、および移行の作成者であるエージェントは、PR上で同じアーティファクトを確認します。
マージ時のブランチのクリーンアップ。 merge.yml はCIプルリクエストブランチ ci-pr-<N> と、リンクされたフィーチャーブランチのLakebaseブランチを破棄します：
マージワークフローの完全な例はこちらで確認できます： merge.yml 非常に多くのブランチが存在するため、孤立した未使用のブランチを削除する週次のクリーンアップスクリプトを用意する価値があるかもしれません。ワークフローの例はこちらで確認できます： cleanup-orphans.yml。最後に、マージ先が「階層化された」ブランチ（ステージングやメイン/本番環境用など。この概念についてはパート3で詳しく説明します）である場合、ユーザーが実際に利用し、常にデータを追加している環境に最終的な移行を 適用する前に、その階層から新しいブランチを切り出して移行をテストするようにワークフローをオーケストレーションできます。
これらのワークフローを組み合わせることで、 すべてのPRが独自のデータベースを持つおよび ブランチは一時的なものであるという性質が、開発者の規律としてではなく、パイプラインの特性として強制されます。
進化的データベース開発のための新しいプレイブック
プラクティス#1：DBAが開発者と緊密に連携する
ルール。 DBAは、ゲートレビューの時だけでなく、機能開発の全期間を通じて開発者と連携します。この連携は、他のコードレビュー担当者が参加するのと同様に、PR内で非同期に行われます。
なぜこれが持続可能な習慣になるのでしょうか？ スキーマの差分と移行テストの結果が、すべてのPRに自動的に反映されるためです（上記の CIでのワークフローの実行方法 を参照）。DBAは、自身のスケジュールに合わせて具体的なアーティファクトをレビューできます。移行はすでに実際のデータを含むCIブランチに対して実行されているため、DBAが頭の中で変更をシミュレーションする必要はありません。
メカニズム：
- DBAは、スキーマに影響を与えるパス（
migrations/、db/、スキーマテストディレクトリ）のCODEOWNERになります。 - DBAは、他のレビュー担当者と同様 に、PR上で非同期にレビューを行います。
- レビューの焦点は、 これによってデータベースが破損するかから これが適切な設計か？ 正しい方法で実装されているか？にシフトします。トピックには、データ整合性ルール、インデックス戦略、設計の一貫性、将来の拡張性、長期的なメンテナンス性などが含まれます。
アンチパターン。 レビューすべき正当なアーティファクトがあるにもかかわらず、DBAをPRフローに含めないこと。
また、DBAの役割には、チーム規模でのポリシー管理やガバナンスにおける新しい責任も加わります。パート3でこれらについて説明します。
プラクティス#2：すべてのデータベースアーティファクトがアプリケーションコードとともにバージョン管理される
ルール：すべての SQL ファイル、マイグレーションスクリプト、スキーマテストは、アプリケーションコードと同じリポジトリに配置します。スキーマの差分（diff）とマイグレーションテストの結果は、PR（プルリクエスト）作成時のアウトプットとしてアーティファクトセットに追加されます。
なぜこれが現在、持続可能な習慣となっているのか？ブランチ作成によって、セットに2つの新しいアーティファクトが追加されます。PRごとのスキーマ差分と、PRごとのスキーママイグレーションテストの結果です。どちらも、実際のブランチの状態から CI によって生成されます。そして、何が変更されたか、また変更マイグレーションスクリプトがどのように実行されたかを示す具体的な証拠として、両方が PR に反映されます。
仕組み：
- バージョン管理されたディレクトリ内のマイグレーションファイル（
migrations/、db/migration/、alembic/versions/など、フレームワークに依存）。 - アプリケーションテストと並んで、テストツリー内にあるスキーマに影響を与えるテスト。
- CI によって PR ごとに生成され、PR のコメントとして投稿されるスキーマ差分。
- CI 実行サマリーおよび PR コメント内のマイグレーションテスト結果。
アンチパターン：PR フローの外（レビュアーが別途開く必要があるダッシュボードなど）でスキーマ差分を生成すること。アーティファクトは、レビューが行われる場所に存在する必要があります。スキーマの変更はコードの変更と紐付いており、この依存関係を壊すと、デプロイ時に下流工程で問題が発生するためです。
プラクティス #3：すべてのデータベース変更をマイグレーションにする
ルール：いかなる環境に対しても、手動での ALTER TABLE は行いません。すべてのスキーマ変更は、バージョン管理され、チェックインされたマイグレーションスクリプトとして実行します。マイグレーションはべき等（idempotent）である必要があります。
なぜこれ が現在、持続可能な習慣となっているのか？「アーティファクトとしてのマイグレーション」というルールは2003年から変わっていません。新しくなったのは、べき等性を担保するという作成時の規律です。移行プロセスの期間中、同じマイグレーションが多くのブランチに対して実行されるため、毎回同じように動作する必要があります。再適用時に失敗するマイグレーションはバグです。
仕組み：
flyway, liquibase, Knex, Alembicなどのマイグレーションフレームワークを使用します。これらのフレームワークは、どのマイグレーションが実行済みで、どれが未実行かを追跡します。これにより、チームはflyway migrateのようなコマンドを適用するだけで、（メタデータテーブルで変更を追跡することにより）まだ適用されていない変更のみを適用できます。- 不可逆な作業は、複数のマイグレーションに分割するのが賢明です。たとえば、新しい列を追加し、元の列を削除する作業を一度に行うマイグレーションは、ロールバックを不必要に困難にします。そのため、まず拡張し、後から縮小する（expand first and contract later）戦略を使用することで、デプロイサイクルによってアクティブなリーダーがそれを参照していないことが確認された後、より多くの選択肢を確保できます。
- 2006年の データベースリファクタリングカタログには、どのリファクタリングが可逆で 、どれが不可逆であるかが記載されています。これを活用しましょう。
アンチパターン：ブランチ内で行われたローカルな変更により、スキーマが特定の「中間状態」にあることを前提としたマイグレーション。マイグレーションは、以前のマイグレーションを含む任意の親ブランチに対して正しく適用される必要があります。
プラクティス #4：全員が専用のデータベースインスタンスを持つ
ルール：開発者ごと、PR ごと、実験ごと、テスト実行ごとに、それぞれ専用の Lakebase ブランチを割り当てます。
なぜこれが現在、持続可能な習慣となっているのか？Docker コンテナを作成したり、ローカルデータベースサーバーをインストールしたり、ライセンスを取得したり、既存のスキーマやテストデータで空のデータベースを満たしたり（ハイドレーション）する余分な手間は、もう必要ありません。シンプルな create-branch Lakebase コマンドを実行するだけで、1TB のデータベースを 1MB のデータベースとまったく同じ「1秒」でブランチ化できます。作成時にデータはコピーされず、変更されたページのみがストレージを消費します。開発者ごと、PR ごと、実験ごとのインスタンス作成が日常的な作業になります。
仕組み：
- 開発者ごとのブランチ：
databricks postgres create-branchまたは SCM 拡張機能のブランチ作成フローを介して、オンデマンドで作成されます。 - PR ごとのブランチ：PR オープン 時に CI によって自動的に作成され（
pr.yml）、マージまたはクローズ時に破棄されます（merge.yml）。PR とマージのスニペットについては、上記の「CI でのワークフローの実行方法」を参照してください。 - 実験ごとのブランチ：設計の検証のためにステージングまたは本番環境からフォークされ、実験終了後に破棄されます。
アンチパターン：「利便性のため」に開発データベースをチーム全体で共有すること。ブランチが統合された瞬間に、パート1で挙げた競合によるシリアライズ（直列化）の問題が再発します。
Jen の例が示す応用範囲：彼女の開発者ごとのブランチは、機能開発の開始時にステージングからフォークされました。CI ブランチは PR オープン時にステージングからフォークされました。彼女の A/B 検証用ブランチ（プラクティス #9）は、並行してステージングからフォークされました。1つの機能に対して4つのブランチが、すべて数秒で、完全に分離された状態で作成されました。
プラクティス #5：開発者がデータベースの変更を継続的に統合する
ルール：すべての PR は、クリーンな Lakebase ブランチに対して CI を実行し、マイグレーションを適用した上で、実際の Postgres に対してテストを実行します。
なぜこれが現在、持続可能な習慣となっているのか？CI パイプラインには 2010 年からマイグレーションの規律が導入されていました。 新しくなったのは、パイプラインごとの分離です。各 PR が独自のブランチを持つため、競合することなく、本番に近い形状のデータに対して統合を実行できます。
仕組み：
- CI は PR オープン時にブランチを作成します。PR のスニペットについては、上記の「CI でのワークフローの実行方法」を参照してください。
lakebase-migrate applyを介してブランチにマイグレーションを適用します。- モックを使用せず、ORM を介してマイグレーション済みのブランチに対してアプリケーションテストを実行します。
- スキーマの差分が PR に投稿されます。
- マージまたはクローズ時にブランチが破棄されます。
アンチパターン：共有のステージング環境に対して PR の検証を実行すること。直列化の問題が再発し、PR ごとの分離という特性が失われます。
プラクティス #6：すべてのデータベース変更をデータベースリファクタリングにする
ルール：スキーマの変更は、列の分割（Split Column）、列名の変更（Rename Column）、列の移動（Move Column）、型の置換（Replace Type）などの定義されたリファクタリングパターンに従います。それぞれに明示的な移行メカニズム（新旧を並行して維持、古いデータから投入、リーダーの切り替え、古いデータの削除）があります。
なぜこれが現在、持続可能な習慣となっているのか？databaserefactoring.com にある 2006 年のカタログには、具体的な例を交えた 70 以上のリファクタリングが記載されています。2026 年における新しい点は、移行メカニズムを低コストでリハーサルできる場所があることです。開発者ブランチでリハーサルを行い、CI ブランチで検証し、本番環境には検証済みの結果のみが反映されます。
仕組み：
- リファクタリングを名前で特定します。カタログで検索してください。
- 開発者ごとのブランチで、定義された移行メカニズムを適用します。本番環境に近い形状のデータに対して検証します。
- PR をオープンします。CI は独自のブランチでマイグレーションを実行し、差分を投稿します。
- 差分とテスト結果が承認されたらマージします。
アンチパターン：定義されたリファクタリングに対応しない、その場限りのスキーマ変更。70 以上のカタログは一般的なケースを網羅しています。もしカタログに該当しない場合は、複数のリファクタリングを1つのマイグレーションにまとめている可能性が高いため、分割する必要があります。
Jenの例のさらなる応用：彼女のV87マイグレーションは、列の分割（Split Column）リファクタリングです。inventory_code を location_code、batch_number、および serial_number に分割します。databaserefactoring.com/SplitColumns.html のカタログページに、移行の仕組みが記載されています。彼女のブランチはリハーサルの場であり、PRの CI 実行が検証の場でした。
プラクティス #7：開発者がオンデマンドでデータベースを更新できる
ルール：開発者はオンデマンドでブランチのデータベース状態をリフレッシュできます。親の現在の状態へのリセット、本番環境からの新しいブランチのフォーク、実験用ブランチの破棄、チームメイトとのブランチの共有など、すべて数秒で実行できます。
なぜこれが今、定着する習慣となるのか？2026年における「オンデマンド」とは、本番環境と同等のデータに対して、隔離された環境で1秒で実行できることを意味します。これらの操作において、運用スケジュールを確認したり、DBA のキューを待ったりする必要は一切ありません。
仕組み：
- リセット：ブランチを削除し、親から再作成します。
- 本番環境からのフォーク：
databricks postgres create-branch --source production。 - 破棄：
databricks postgres delete-branch。 - 共有：ペアリングセッションのために、ブランチのエンドポイントをチームメイトに渡します。
アンチパターン：目的を超えてブランチを永続的なものとして扱うこと。マイグレーションこそが永続的な成果物であり、ブランチは単なるワークスペースです。
プラクティス #8：デフォルトの選択肢としての破壊的テスト
ルール：破壊的なアクションの影響範囲（ブラスト半径）がゼロであれば、破壊的テストは四半期に一度のイベントではなく、日常的な選択肢になります。
なぜこれが今、定着する習慣となるのか？ブランチは1秒でリセットできます。ブランチに対して行うあらゆる操作は、同じ親から新しいブランチを作成することで元に戻せます。破壊的テストに運用スケジュールや承認ゲートは不要になります。
通常の機能開発サイクルに組み込めるようになったこと：
- 「UPDATE 文の途中でマイグレーションが失敗したらどうなるか？」実行してみましょう。50%の時点でプロセスを強制終了します。ロールバックが機能することを確認します。そしてリセットします。
- 「バックアップと復元の途中でフェイルオーバーが発生したらどうなるか？」不完全な状態をシミュレートします。アプリケーションの動作を検証します。そしてリセットします。
- 「DR ランブックの実際の復旧時間はどれくらいか？」ランブックを実行します。測定します。そしてリセットします。
- 「このマイグレーションは本番環境と同等のデータやサイズに対して正常に実行できるか」コミット前に検証します。
カルチャーへの影響：リセットのコストがゼロになると、チームはテストデータベースを「貴重で壊してはいけないリソース」として扱わなくなります。テストを積極的に行 うことができます。次のブランチはまっさらな状態から始まるため、クリーンアップを省略できます。
Jenの例のさらなる応用：PR を作成する前に、彼女はブランチ上の本番環境と同等のデータを取り込み、inventory_code の値の約1%を意図的に破損させて、桁落ち、スペースの混入、末尾の空白などのエッジケースを再現しました。これらは、過去のデータが蓄積していく中で発生しがちなノイズです。彼女がマイグレーションを実行したところ、2行が部分文字列（substring）の計算で失敗しました。彼女はスクリプトを修正して再実行しました。ブランチがこの破壊的テストを吸収したため、本番環境に影響が及ぶことはありませんでした。
プラクティス #9：データベースレベルでの A/B バリアントプロトタイピング
ルール：2つの設計案が対立している場合は、並行するブランチでそれぞれを構築し、本番環境と同等のデータと比較して、より優れたソリューションを採用します。
なぜこれが今、定着する習慣となるのか？ブランチごとのコストがほぼゼロだからです。2つのスキーマ設計を検討する際、事前にどちらか一方に絞り込む必要はありません。また、調査段階の疑問のために、ほとんどのチームが敬遠するようなプロビジョニングプロセスを行う必要もなくなります。
仕組み：
- 同じ親から2つのブランチを作成します。
- 一方のブランチに設計案Aのマイグレーションを適用し、もう一方に設 計案Bのマイグレーションを適用します。
- それぞれに対してアプリケーションを実行します。一般的な読み取りパスにおけるクエリレイテンシ、本番規模でのマイグレーション時間、インデックスのフットプリント、シミュレートされた負荷下でのロック競合など、重要な指標を測定します。
- 優れたソリューションを選択し、最適でないソリューションは破棄します。次にスキーマを拡張する人が、何が検討され、なぜこの設計が選ばれたのかを把握できるように、決定事項を PR の説明に記録します。
アンチパターン：決定事項とその理由を記録せずに A/B プロトタイプを実行すること。ブランチは一瞬で消え去りますが、設計の決定は永続的なものであるべきです。
Jenの例のさらなる応用：彼女は、ロケーション/バッチ/シリアル機能に対して2つの設計を検討しました。既存の inventory テーブルに3つの新しい列を追加するか、将来的に属性が追加されることを見越して inventory_id をキーとする別の inventory_attributes ルックアップテーブルを作成するかです。彼女はステージング環境から分岐した並行ブランチで両方を構築しました。それぞれに対してアプリケーションの読み取りパスを実行し、本番環境と同等のデータに対するクエリパフォーマンスを測定し、各マイグレーションが本番規模にどのようにスケールするかを確認しました。ルックアップテーブル版は、在庫を表示するたびに結合（join）が必要になるため、一般的な読み取り パスでのパフォーマンスが低下しました。彼女は列を追加するバージョンをリリースし、ルックアップテーブルのブランチを破棄して、PR の説明に次のメモを残しました：ルックアップテーブル版も検討しましたが、一般的な読み取りパスが結合処理になるため却下しました。属性が5つ以上増えた場合は再検討してください。
Jenの新しいプレイブックが示すもの
私たちは、2003年当時の7つのプラクティスと、そのうち5つを理想論にとどめていた制限事項を挙げ、ブランチ機能が実現した2026年に向けてそれらを再構築し、ブランチ機能によって可能になった4つの新しいプラクティスを追加しました。「進化型データベース開発（Evolutionary Database Development）」の新しいプレイブックには合計11のプラクティスがあり、そのうち9つを上記で説明しています。
パート1 — Jenのストーリー：1つの機能、1つのデータベースでは、Jenが1つの機能に取り組む様子を見ました。彼女はコードブランチと Lakebase ブランチをペアにし、本番環境と同等のデータに対して実際のマイグレーションを数秒で実行し、モックなしでテストし、スキーマの差分をインラインで投稿した PR を作成し、マイグレーションを適用して一時的なブランチをクリーンアップした状態でマージしました。データベースの変更は、通常の開発プロセスの一部となりました。
パート3 — 大規模環境におけるJenの チームでは、50人の開発者規模におけるプレイブック、ポリシー管理とガバナンスにおける DBA の進化した役割、そしてJenと並行してブランチを作成するエージェントについて見ていきます。プラクティス #10 と #11 については、そこで詳しく解説します。
コンパニオン：プラグインのウォークスルーでは、VS Code および Cursor 用の Lakebase SCM 拡張機能について説明します。
エージェント向けの Lakebase App Dev Kit と、人間の開発者向けのコンパニオン電子書籍が、後日リリースされる予定です。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
最新の投稿を受信トレイで受け取る
ブログを購読して、最新の投稿を受信トレイにお届けします。