Lakebaseのデータベース分岐をCI/CDへ組み込む実践パターン

Databricksは、GlaspoortがLakebaseのデータベース分岐をコードのブランチに近い形で扱い、CI/CDへ組み込んだ本番事例を紹介しました。

要点

• 開発環境と受け入れ環境を、階層化せず本番から直接分岐させ、親の再設定時に子を削除する問題を避けます。
• PRごとに本番から有効期間1時間の一時ブランチを作り、マイグレーションと新しいアプリ画像を組み合わせて試験します。
• データベース同士はマージせず、順序付けたマイグレーションをスキーマの唯一の正本として各環境へ再適用します。

今回のブログ記事で語られていること

Lakebaseのブランチは、親の状態をコピーオンライトで分岐し、独立した接続先とデータを数秒で用意するPostgres環境です。ただしGitと違い、親からブランチを再設定するには、そのブランチが持つ子を先に削除する制約があります。開発を本番の子、受け入れを開発の子、各機能を開発の子にする階層では、開発環境を本番の新しいデータへ戻すたびに、受け入れ・機能ブランチの削除、接続先の再設定、権限の再付与が必要になります。Glaspoortはこれを避けるため、長寿命の開発環境と受け入れ環境をどちらも本番から直接分岐させ、互いに親子関係を持たせていません。これにより、一方を本番から更新しても他方を作り直さずに済みます。

日々のCIでは、PRごとに本番からpr-xxxxという一時ブランチを作ります。有効期間は1時間で、PRが閉じた時点でアーカイブし、プロジェクト当たり未アーカイブ10ブランチという既定上限の内側に収めます。変更にマイグレーションが含まれる場合は、新しいブランチへ順番に再適用します。さらに、新しいアプリ画像をステージングスロットへ配置し、その画像をマイグレーション適用後のブランチへ接続して、アプリとDBの組み合わせに対する全試験を実行します。PRをマージした後も、本番から分岐し直してマイグレーションと試験を再実行します。開発、受け入れ、本番への昇格には手動承認ゲートがあり、各段階で対象ブランチへマイグレーションを適用します。

重要なのは、Glaspoortがデータベースをブランチ間でマージしていない点です。短命なDBブランチは検証のために捨てられる環境で、永続的な正本は順序付けたマイグレーションです。昇格とは機能ブランチのデータを開発へコピーすることではなく、同じマイグレーションを対象環境へ再実行することを意味します。ソース管理側も長寿命の開発・リリースブランチを持たず、masterだけを使い、環境間の進行はAzure DevOpsの手動ゲートで表現しています。

PRをいつマージ可能にするかについては、CI合格直後にマージする方式と、開発・受け入れまで昇格してからマージする方式を比較し、小規模で変更が重なるGlaspoortは前者を選びました。速度を優先する代わりに、積み上がったマイグレーション一式を毎回本番の新しい分岐上で再検証し、緊急修正には同じ事前試験を通って本番へ直接進む別の緊急用パイプラインを用意しています。認証は60分で失効するDB資格情報を接続プール側で更新し、オブジェクト権限は現時点では本番へ手動適用、DB接続は単一のアプリ利用者とし、個人別の認可はアプリ層で行う構成です。これはLakebase一般の必須設定ではなく、Glaspoortが採った運用上の選択です。

今回のブログ記事が関係する人

Lakebaseを使うアプリケーション開発者、データベース管理者、プラットフォームエンジニア、CI/CDと本番変更の承認を管理するチームに関係します。

結局、今回のブログ記事をどう読むべきか

この事例の要点は、DBをコードのように「マージ」することではありません。本番から新鮮な短命ブランチを作り、アプリ画像とマイグレーションを一緒に試験し、同じマイグレーションを承認済みの対象環境へ再適用することです。採用時は、ブランチ上限、資格情報更新、権限管理、緊急経路まで含めて自社向けに設計する必要があります。