初めてこちらのFAQに質問を投稿させていただきます。
Bubbleでの運用に関して課題に直面しており、もし同じような経験をお持ちの方や解決策をご存知の方がいらっしゃれば、ご意見・アドバイスをいただけますと大変助かります。
どうぞよろしくお願いいたします。
1. 前提条件
- Bubbleで構築したアプリを、社内（A社）と他企業で共通利用している。
- 新しい機能やフローをまずはA社だけで試験運用したいニーズがある。
- 現状、ステージング環境は明確に分かれていない。
2. 発生している問題
同一の本番アプリ内で複数企業が利用しているため、新機能を試験的に実装・公開すると、すべての企業に影響が出てしまう。A社のみでの事前検証や試運用が困難。
3. エラーメッセージ
特にBubble上のエラーメッセージは発生していませんが、運用上の課題として困っています。
4. 実装したい機能
Bubbleアプリにて：
- A社のみが新機能を先行利用・検証できる仕組みを導入したい。
- 他の企業には、新機能をまだ非表示・非公開のままにしておきたい。
5. スクリーンショット
※運用の質問のためありません
6. 試したこと （考えてみた運用方法）
-
方法①：別アプリとしてステージング環境を作成し、手動で反映する
→ アップデートのたびに手動でコピーする必要があり、工数・ヒューマンエラーのリスクが高い。
-
方法②：アップデートのたびにアプリを完全複製し、A社メンバーには都度最新の複製アプリにログインしてもらう
→ 外部アプリとの連携が都度必要で、複製ごとの更新作業が多く非効率。
-
方法③：同一環境内で、Conditionにより企業ごとに表示・機能を制御する
→ 設定箇所が多い場合に条件設定の漏れや外し忘れのリスクがあり、運用が不安定になる可能性あり。
-
方法④：A社のみ開発環境を使う
→ テストデータの扱いが難しく、他ユーザーに影響が出る可能性があるため現実的ではない。
どの方法にもそれなりのデメリットがあり、実装・運用方法に行き詰まっています。
上記以外の良い手段があれば教えていただきたいです。
またbubble初心者・開発初心者のため、どのような観点で考えると良いか等のアドバイスも頂けますと幸いです。
7. 補足情報（調べたURL/参考になりそうな事例）
- Bubble公式フォーラム内での「ステージング環境の作り方」「ユーザーごとの表示切り替えに関するCondition設定」などの記事を確認
- 外部連携の多いアプリでは、複製ごとにAPIキーなどの再設定が必要になることも懸念事項として共有されている
ご回答お待ちしています。よろしくお願いいたします。
※※※※※※※※※※※※※※※※※※
この返信はAIによる自動応答です。
トピック作成時のみに投稿されます。
※※※※※※※※※※※※※※※※※※
Bubbleでの運用に関する課題について、以下の解決策を提案します。
-
Feature Flagsを活用する:
- A社のみを対象に新機能を有効化する「Feature Flags」を実装します。ユーザーの属性や企業情報に基づいて機能を動的に切り替えることで、特定のユーザーグループにのみ新機能を提供できます。
-
ユーザーロールの活用:
- A社のユーザーに特定のロールを付与し、そのロールに基づいて新機能を表示するかどうかを条件設定します。これにより、他の企業には新機能を非表示にできます。
-
専用のテストグループを作成:
- A社専用のテストグループを作成し、そのグループにのみ新機能をテスト公開する方法もあります。ユーザー管理をしっかり行うことで、運用面のリスクを減らせます。
-
ステージング環境の活用:
- 可能であれば、ステージング環境を設置してA社だけがアクセスできるようにし、そこで試験運用を行うのも良いでしょう。
これらの方法を組み合わせて運用することで、A社のみでの新機能試験運用がより効率的かつ安全に行えるようになるでしょう。まずは、Feature Flagsの実装が手軽で効果的なので、試してみることをお勧めします。
より詳細な設定方法など、公式ドキュメントやフォーラムも参考にすると良いでしょう。
Bubbleのフォーラム
- 方法④：A社のみ開発環境を使う
→ テストデータの扱いが難しく、他ユーザーに影響が出る可能性があるため現実的ではない。
この方法④が少し理解できてないのですが、
BubbleではStarterプラン以上であれば、開発用（ステージング）環境として「version-test」というURLが自動で用意されてますよ。
開発環境をA社専用として使うには：
https://yourapp.bubbleapps.io/version-test が開発環境のURLです。- このURLをA社の関係者にだけ共有することで、新機能の先行テストが可能です。
- この環境は本番のデータやユーザーとは完全に分離されているため、安心して検証が行えます。
そのため、開発環境では、他のユーザーに影響がでることはありません。
ただ、開発環境用のA社のデータと、本番環境用のA社のデータが”別に”ますので、
厳密な先行利用ではないですが、本当に分けたいなら、 Condition で管理するのがいいと思います。（例：サブスクリプションユーザーだけ見れるような優待機能を実装しているイメージですね。割と、仕様としてはリッチな気がしますが。）
ご回答ありがとうございます！
テスト環境の共有も考えたのですが、
アプリ自体が開発途中のため日常的に更新がかかってしまうことから、
現実的ではないと判断し断念することとなりました。
最終的にはSub appsを利用する方針に変更し、
親アプリにA社、子アプリにその他の企業を入れることで
手動アップデートを回避した上で、環境を分けることが可能になりました。
tsubasa様のおっしゃる通り Conditionでの管理も併用していく予定です。
nanaさん、返信ありがとうございます。
アプリ自体が開発途中のため日常的に更新がかかってしまうことから、現実的ではないと判断し…
確かに、開発が活発なフェーズではversion-testの運用がかえって煩雑になるケースもありますよね。その方針で良いと思います。
最終的にはSub appsを利用する方針に変更…
この切り替え、とてもスマートですね
Sub Appsで親子構成に分けておくと、将来的な環境管理やデプロイ戦略も柔軟に取れるので、いいと思います。
あと補足になりますが、今後のレベルアップ課題として、
Sub App間で同じAPIキーなどを使い回す場合は、権限管理やリファレンスの整理も意識しておくと、後々の保守がぐっと楽になっていくと思います。
【参考】
＃authentication
API Connector security
＃the-data-api/authentication
Condition併用も含めて、理想的な構成だと思います。今後もうまく運用が進むよう願っていますー。