Firebaseのstagingとproductionの切り分けには大きく分けて2通りのアプローチがある
- 1project内にproduction / staging向きアプリを登録する
- project自体を分ける
必須でprojectを分けるパターン
- Cloud Firestoreを利用する場合
- Cloud Functionsを利用する場合
- Storageを利用する場合
- Hostingに静的サイトを構築する場合
上記の機能は、1projectに1つの環境しか作れないので、projectを分ける必要がある
それぞれローカルで作業して、Firebase CLIやCIを経由でデプロイするフローを踏むことになるので、運用的にもproject自体を分けることになる
CLIで環境の切り替え方:
https://firebase.google.com/docs/cli?hl=ja#project_aliases
必須じゃないけど分けた方がいいパターン
Authentication, Remote Config, FCMなど本番ユーザーに影響しかねない設定を触る場合
- Remote Configのキー名を
hogehoge_stgのように運用で分けても良いが、同じprojectに本番・ステージの環境変数が乗っかっているのは事故の元になる - FCMも、ターゲットのアプリを慎重に切り替えれば良いが人的ミスの温床になる
- Authenticationも言わずもがな
ユーザー数が少ない状態でAnalyticsを頻繁にウォッチする場合
たとえアナリティクスだけしか使わない(予定)のアプリだとしても、
ダッシュボードで毎回、productionのアプリにフィルタをかけないと調査データが濁るので、ユーザー数が少ないアプリは注意が必要。
これを毎回やるくらいならprojectを分けた方がいい
結論
将来的に分ける場合、移行が面倒だったりするので少しでもFirebaseを利用するなら最初から分けたら良いと思う。
そして、productionの環境を編集できる人は権限を厳密に管理すれば事故りにくい
宣伝
フルFirebaseで実装した個人アプリをリリースしました!! 
下記の機能をフル活用したアプリです。
家族・カップルのタスク管理にお困りの方、是非使ってみてください
- Analytics
- Authentication
- Crashlytics
- Firestore
- Storage
- Cloud Messaging
- In-App Messaging
- Storage
- Remote Config
- Dynamic Links
