Share
Embed
Transcript
36 slides
-
・NoritakaIkeda ・X(Twitter): @omotidaisukijp ・ROUTE06 Liam開発部 ・好きなAI Agent: Devin 自己紹介 2
はじめに Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 -
• DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 • Supabase BranchingとClaude Code GitHub
Actionsで、 エディタを使わない開発フロー 6 はじめに Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 今日話すこと -
DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 8 DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 Supabaseに支えられて可能となった
AIコーディング時代の新しい開発プロセス事例の紹介 マルチテナント SaaSのRLSを実装する際、 DB TriggerとDB FunctionとDevinで並列実装をした - アプリケーション側のコードに影響することなく実装を進められた - 並列で一貫した品質の実装を、一人で、数日の間にパワフルに完了できた - このプロセスを、 RLSに限らず、リアーキテクチャの際に参考にしていただけたら嬉しい -
布教したいツール・機能の紹介①・② 9 Supabase BranchingとClaude Code GitHub Actionsで、 エディタを 使わない開発フロー Supabaseに支えられて可能となった
AIコーディング時代の新しい開発プロセス事例の紹介 Database Function Database Functions とは、PostgreSQLの関数(Function)を使って、再利用可能なロジックをデータベー ス内に定義する仕組みのこと Postgres Triggers データベース内で特定のイベントが発生したときに自動的に実行される関数(関数呼び出し) https://supabase.com/docs/guides/database/functions https://supabase.com/docs/guides/database/postgres/triggers -
布教したいツール・機能の紹介③ 10 Supabase BranchingとClaude Code GitHub Actionsで、 エディタを 使わない開発フロー Supabaseに支えられて可能となった
AIコーディング時代の新しい開発プロセス事例の紹介 Devin "The first AI software engineer." (「世界初の AIソフトウェアエンジニア」) コードの記述、アプリの構築とデプロイ、バグ修正、ドキュメントからの学習まで、すべて を自律的にこなします。 https://devin.ai/ -
RLS導入の背景 11 DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 マルチテナント SaaSの要件
- マルチテナント SaaSとは、複数の顧客(テナント)が同じ 1つのソフトウェアインスタンスやインフラを共有しながら も、それぞれが独立してサービスを利用できる形態の SaaS 同じ1つのソフトウェアインスタンスやインフラを共有 - DBも共有する。 - 共有はするが、テナント Aに所属する顧客が、テナント Bに所属する顧客のデータにアクセスできないようにした い Row Level Securityとは - ユーザーごとにアクセスできる「行(レコード)」を制限するセキュリティ機能 - https://supabase.com/docs/guides/database/postgres/row-level-security - https://www.postgresql.jp/docs/9.6/ddl-rowsecurity.html -
RLS導入までの道のり 12 DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 1. 設計・実装の方針を立てる
2. モデルケースを作成する 3. Devinに依頼してすべてのテーブルに対して PRを作成する 4. 人の目で確認して PullRequestをオープンにしていく 5. レビューしてもらい、 Mergeする -
RLS導入までの道のり 13 DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 1. 設計・実装の方針を立てる
2. モデルケースを作成する 3. Devinに依頼してすべてのテーブルに対して PRを作成する 4. 人の目で確認して PullRequestをオープンにしていく 5. レビューしてもらい、 Mergeする -
RLS導入の際の懸念点 14 DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 アプリケーション側への影響が大きくなりそうなことが見込まれる -
すべてのテーブルへ Organization Idカラムを追加する際、それらのテーブルへの INSERTやUPDATEにすべて Organization Idフィールドを追加しないといけない - 挿入するOrganization Idは、アプリケーションコード側で、親テーブルから fetchしてくる必要がある。 すべてのテーブルに Organization Idカラムを持たせる以外の方法はない? - RLSのポリシーに親や祖先のテーブルから joinして記述方法もあるが以下の理由で見送り - ポリシーが複雑になり、ヒューマンエラーからセキュリティホールが生まれるリスク - あるテーブルにアクセスしようとしたとき、そのテーブルの RLSポリシーを判定しようとすると、それに関連する親 のRLSポリシーも判定ないといけなくなり、 RLSでアクセスが拒否された時のデバッグが大変 -
アプリケーション側へ影響を最小限にした RLS導入戦略 15 DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 DB
Trigger・DB Functionsを用いて、 SQLファイルのみに影響するような実装を進めていく CREATE OR REPLACE FUNCTION public.set_knowledge_suggestions_organization_id() RETURNS trigger AS $$ BEGIN NEW.organization_id := ( SELECT organization_id FROM public.projects WHERE id = NEW.project_id ); RETURN NEW; END; $$ LANGUAGE plpgsql SECURITY DEFINER; CREATE TRIGGER set_knowledge_suggestions_organization_id_trigger BEFORE INSERT OR UPDATE ON public.knowledge_suggestions FOR EACH ROW EXECUTE FUNCTION public.set_knowledge_suggestions_organization_id(); -
アプリケーション側へ影響を最小限にした RLS導入戦略 16 DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 この方針をベースに、
ADRを作成しました - チームで合意する際にも、 AIに任せる際にも便利です。 - OSSのリポジトリで公開しています : https://github.com/liam-hq/liam/blob/main/frontend/apps/docs/content/docs/contributing/adr/20 250421-apply-rls-to-all-tables-with-organization-based-policies.mdx -
RLS導入までの道のり 17 DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 1. 設計・実装の方針を立てる
2. モデルケースを作成する 3. Devinに依頼してすべてのテーブルに対して PRを作成する 4. 人の目で確認して PullRequestをオープンにしていく 5. レビューしてもらい、 Mergeする -
RLSを適用するモデルケースの作成 18 DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 Devinに並列で依頼する前に、チームのコード品質に準拠した PRを作成する
- あらかじめ作成した大まかなプロンプトで Devinへ依頼する - コード品質を安定させるために、結構人の手を入れながらプロンプトの精度を上げていく - PRが完成したら、「ここまでの実装を他のセッションでも行えるようにプロンプトにして」と依頼 -
RLS導入までの道のり 19 DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 1. 設計・実装の方針を立てる
2. モデルケースを作成する 3. Devinに依頼してすべてのテーブルに対して PRを作成する 4. 人の目で確認して PullRequestをオープンにしていく 5. レビューしてもらい、 Mergeする -
RLS導入までの道のり 22 DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 1. 設計・実装の方針を立てる
2. モデルケースを作成する 3. Devinに依頼してすべてのテーブルに対して PRを作成する 4. 人の目で確認して PullRequestをオープンにしていく 5. レビューしてもらい、 Mergeする あまりこの発表の本筋ではないので細かくは補足しません。 より詳細な話はブログに記載しています。 “マルチテナント SaaSでのRLS導入に際し、方針策定から Devinを活用した並列実装までを行った 実践例” , https://liambx.com/ja/blog/multi-tenant-saas-rls-devin-guide -
DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 23 DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 Supabaseに支えられて可能となった
AIコーディング時代の新しい開発プロセス事例の紹介 マルチテナント SaaSのRLSを実装する際、 DB TriggerとDB FunctionとDevinで並列実装をした - アプリケーション側のコードに影響することなく実装を進められた - 並列で一貫した品質の実装を、一人で、数日の間にパワフルに完了できた - このプロセスを、 RLSに限らず、リアーキテクチャの際に参考にしていただけたら嬉しい -
エディタを 使わない開発フロー 25 Supabase BranchingとClaude Code GitHub Actionsで、 エディタを 使わない開発フロー
Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 GitHub上から指示を行い、自動でプレビュー環境のデプロイまで完了した話 - 実現した開発フロー - この開発フローを行うためのツール構成 - 肌で感じた、この開発フローの利点 今回の発表で話さないこと - 個別のツールの具体的なセットアップ方法 -
布教したいツール・機能の紹介④ 26 Supabase BranchingとClaude Code GitHub Actionsで、 エディタを 使わない開発フロー Supabaseに支えられて可能となった
AIコーディング時代の新しい開発プロセス事例の紹介 Supabase Branching Supabaseブランチは、メインプロジェクトから独立した独立した環境を作成します。これらのブランチ環境を使 用することで、本番環境に影響を与えることなく、新しい設定、データベーススキーマ、機能などの変更を作成 ・テストできます。 https://supabase.com/docs/guides/deployment/branching -
布教したいツール・機能の紹介⑤ 27 Supabase BranchingとClaude Code GitHub Actionsで、 エディタを 使わない開発フロー Supabaseに支えられて可能となった
AIコーディング時代の新しい開発プロセス事例の紹介 Claude Code GitHub Actions Claude Code GitHub ActionsはAI駆動の自動化を GitHubワークフローにもたらします。任意の PRやissue で簡単に@claudeとメンションするだけで、 Claudeが コードを分析し、プルリクエストを作成し、機能を実装し、 バグを修正します - すべてプロジェクトの標準に従いな がら。 https://docs.anthropic.com/ja/docs/claude-code/github-actions -
エディタを 使わない開発フロー 28 Supabase BranchingとClaude Code GitHub Actionsで、 エディタを 使わない開発フロー
Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 - 実現した開発フロー - この開発フローを行うためのツール構成 - 肌で感じた、この開発フローの利点 -
従来の開発フロー 29 Supabase BranchingとClaude Code GitHub Actionsで、 エディタを 使わない開発フロー Supabaseに支えられて可能となった
AIコーディング時代の新しい開発プロセス事例の紹介 1. ローカル環境を立ち上げる 2. コードをエディタ上で修正する 3. うまくできたら PRを作成する 4. プレビュー環境で最終動作確認 5. レビューコメントが来ていたら修正する 6. うまく行ったら Mergeする -
実現した開発フロー 30 Supabase BranchingとClaude Code GitHub Actionsで、 エディタを 使わない開発フロー Supabaseに支えられて可能となった
AIコーディング時代の新しい開発プロセス事例の紹介 1. ある Issue or PullRequest で @claude とメンションをつけて、実装して欲しい内容を指示する 2. 待っていたら PRができるので、 VercelとSupabaseのブランチングによって動作するプレビュー環境で動 作確認をする。 3. レビューエージェントとともにレビューする 4. 気になるところは、 @claude とメンションをつけて修正依頼 or 新しいPR作成依頼をする 5. 良さそうだったら Mergeする -
エディタを 使わない開発フロー 31 Supabase BranchingとClaude Code GitHub Actionsで、 エディタを 使わない開発フロー
Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 - 実現した開発フロー - この開発フローを行うためのツール構成 - 肌で感じた、この開発フローの利点 -
この開発フローを行うためのツール構成 32 Supabase BranchingとClaude Code GitHub Actionsで、 エディタを 使わない開発フロー Supabaseに支えられて可能となった
AIコーディング時代の新しい開発プロセス事例の紹介 Issue @claude メンション PR GitHub Apps Claude Code Action GitHub Actions Vercel デプロイの発火 Supabase Preview GitHub プレビュー環境 -
エディタを 使わない開発フロー 33 Supabase BranchingとClaude Code GitHub Actionsで、 エディタを 使わない開発フロー
Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 - 実現した開発フロー - この開発フローを行うためのツール構成 - 肌で感じた、この開発フローの利点 -
肌で感じた、この開発フローの利点 34 Supabase BranchingとClaude Code GitHub Actionsで、 エディタを 使わない開発フロー Supabaseに支えられて可能となった
AIコーディング時代の新しい開発プロセス事例の紹介 プレビュー環境の作成が容易 - 本番環境・ステージング環境・プレビュー環境用にそれぞれインフラを用意したり、構成を考えて実装する 必要がない。直感的に作成できる。 小さな修正や、片手間に検証したい実装を手軽に試せる - 小さな修正の場合、意図通りに完了することが多く、省力できる - 片手間で検証ができるので、何通りか試してみて、うまくいかなかったら Closeするという使い方ができる 実装とコードレビューがすべて GitHub上で完結する体験の良さ - コードを見ながら思いついた追加機能や改善をその場で IssueにしたりPRにできる、疾走感がある -
この開発フローでは向かないタスク 35 Supabase BranchingとClaude Code GitHub Actionsで、 エディタを 使わない開発フロー Supabaseに支えられて可能となった
AIコーディング時代の新しい開発プロセス事例の紹介 あまりコードベースを理解していない箇所の対応 - GitHub上だとコードの情報量が限られる。エディタの方が短時間で複雑なコードを理解しやすい。 大規模で複雑な箇所の対応 - コードベースが大きくなると、レビュー負荷が高すぎて、本番に入れるコードにするのには大きな労力が かかることが多い -
• DB Trigger・DB FunctionとDevinで行なった、 RLSの並列実装 • Supabase BranchingとClaude Code GitHub
Actionsで、 エディタを使わない開発フロー 36 終わりに Supabaseに支えられて可能となった AIコーディング時代の新しい開発プロセス事例の紹介 今日話したこと