Shunk

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

Created Mon, 26 Aug 2024 17:59:20 +0900

前の記事はgoogle主催のgemini API Competitionに参加して学んだことまとめ

はじめに

この記事は、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分もかからず導入できると思われる。

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

導入手順

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

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

総評

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

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

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

続報が気になる。

次の記事はgoogle推奨Androidアーキテクチャを理解する「データレイヤ」編