Shunk/supabaseのブランチングを試してみた

はじめに

この記事は、supabaseのmeetupで発表した内容を記事化したものです。

supabaseの右上に突如出現した謎の「Enable Branching」ボタン。このボタンの謎を追うために、調査隊はAmazonの奥地に向かった。

「Enable Branching」ボタンは2024年4月に、正式公開（Publicly Available）になったSupabaseの新機能である。

より正確に言えば、Supabse Cliの一つの機能であると言える。

この機能を使うと、DevOpsエンジニアが頑張って環境を整えなくても、プレビュー環境が簡単に作れるようになるという機能だ。

指定したブランチへのPRが作られた時点で、そのPRに対するプレビュー環境が自動で立ち上がる。 PR内にsupabaseの変更をコミットしておけば、変更を取り入れた形でプレビュー環境が立ち上がる。

PRがマージされると環境ごと自動で削除される。使い捨ての環境がパパッとできるイメージ。

ちなみにプレビュー環境は新しく作られるので、中身のデータは入っていない。もし入れたければseedファイルに事前に定義しておかなければいけない。

プレビュー環境を作る手間をほぼゼロにすることができる。また、従量課金で初期コストがかからないので、プレビュー環境を作る余裕がない状況だと非常に強いと思われる。

また、個人的に便利だと思ったのはvercelのプレビュー機能との連携。 PRを作った時にvercelでもプレビュー環境が自動で出来上がる。そしてSupabaseの方で作ったプレビュー環境と自動で結びついてくれる。

要は環境変数の設定をサービス同士で自動化してくれている。

これは便利。

料金面で言うと、Supabaseのプロプランに上げる課金代金が必要。(公式の料金表) 現在は25ドルなので4000円くらい

プラスしてBranching機能自体も、プレビューブランチひとつごとに課金がある。

$0.32 per branch, per day とのことなので、1日1プレビューブランチで45円くらい。 1日平均1つのプレビューブランチを作ると、月に1350円くらいかかる。

手間自体は非常に少なく、docker がすでに使えたり、supabase cliを既に有効化しているならば 30分もかからず導入できると思われる。

また、普段の開発フローを変える必要がないので、開発者にも負担は少ない。

基本的には公式ドキュメント通りに行えば良いので割愛するが、一部公式ドキュメント通りにいかない箇所があった。

DB pullが失敗する(マイグレーション履歴が違うというエラー)→migration repairコマンド実行
migration repairコマンドが失敗する(リンクされていないというエラー)→supabase linkコマンドを実行して作成したsupabaseプロジェクトを選択する
上記を実行後に再度DB pullが失敗(lrupscが既に存在しているというエラー)→db pullのポートを6543から5432に変更(参考)

Supabase branchingは全開発者が喜ぶ新機能というわけではないが、新規プロダクトを立ち上げたタイミングや、DevOpsを整えようとするタイミングには非常に有効だろうなと感じた。

導入の手間が少ないのが大きい。

一方でドキュメントにもあるようにまだ本番で使うには危険性があるのと、対応しているプラットフォームが少ないという問題があると感じた。

続報が気になる。