Bubbleには開発中の変更を試す版と、利用者が触れるLive版があります。公開ボタンを押す前に、画面だけでなくデータ・権限・外部連携を含めて確認すると、運用中のトラブルを減らせます。
01開発版で確認する範囲
新しい画面やWorkflowが動くかに加え、既存の機能が壊れていないかを確認します。管理者、一般利用者、未ログインの人など、権限の異なる立場で試しましょう。テストに使うデータと本番データを混同しないことも重要です。
02変更内容を記録する
何を直したか、関連するページ・Workflow・データ型、確認したケースを短く記録します。複数人で作業する場合は、誰の変更がいつLiveに反映されるか共有します。公開の単位を小さくすると、問題が起きたときに原因を追いやすくなります。
03外部連携を点検する
APIキーや接続先、通知メール、Webhookなどは、開発環境で成功してもLiveで同じとは限りません。実際の本番設定と権限を確認し、誤送信や二重処理が起きない試験方法を決めてください。
04公開後までを手順にする
公開直後に主要な操作を短く点検し、問い合わせやエラーを確認する担当者を決めます。想定外の問題が出たときの差し戻し方法も事前に把握しましょう。公開作業は完了の合図ではなく、利用者に影響がないかを確認する工程まで含みます。
05具体例：申請アプリに「差し戻し」を追加する場合
開発版で承認画面に差し戻しボタンを追加したとします。正常な1件だけでなく、「理由が空なら差し戻せない」「差し戻された本人だけ内容を直せる」「承認済みの申請は差し戻せない」を一般利用者と管理者の両方で試します。変更した画面、Workflow、Data type、Privacy Rulesを記録し、従来の申請・承認フローも通します。開発版とLive版のデータや外部サービスの設定が同じとは限らないため、試験用の通知先を確認してから操作します。
公開手順には、担当者、実施時刻、変更内容、確認する3件程度の代表操作、問題が出たときの連絡先を残します。Liveへ反映した後は、実際のLive URLで申請→差し戻し→再申請を試し、意図しない通知や二重処理がないか見ます。変更後の状態でしか作られないデータがある場合、単に以前の画面へ戻しても元に戻らないことがあります。差し戻しの方法は変更内容に応じて事前に決めてください。
参考資料
内容は公開時点の公式資料をもとに構成しています。仕様は変更されることがあるため、導入時は最新の公式情報をご確認ください。