Firebase 上市檢查清單

本文提供一份檢查清單，列出將 Firebase 應用程式發布至正式環境前，應考量的事項和最佳做法。

發布的一般最佳做法

  • 請務必先在Firebase Local Emulator Suite (適用於支援的產品) 中測試所有變更，再部署至正式環境。徹底測試有助於避免付出高昂代價。

  • 開始對所有支援 Firebase App Check 的服務強制執行該政策。App Check 有助於確保只有實際應用程式可以存取後端服務和資源。

  • 查看 Firebase 的一般安全性檢查清單。

  • 使用 Firebase Remote Config 推出功能，安全地逐步發布應用程式的新功能和更新。

  • 如果您尚未設定 Firebase Crashlytics，建議您進行設定。這項輕量級的即時當機回報工具，可協助您追蹤、排定優先順序，並修正影響應用程式品質的穩定性問題。

瞭解定價方案限制並設定預算快訊

  • 請確保正式版上線後，用量不會超過用量限制和配額，特別是使用免付費 Spark 方案時。建議升級至即付即用 Blaze 定價方案。

  • 為專案設定預算快訊。

    • 請注意，預算快訊並非預算上限。當您接近或超過設定的門檻時，快訊會傳送通訊，以便您在應用程式或專案中採取行動。

    • 建議您設定進階快訊和動作，例如在收到快訊時停用計費功能。

    • 如果您使用 Firebase AI Logic、Firebase App Hosting、Cloud Functions for Firebase 和 Firebase Extensions，強烈建議您設定支出上限，這樣一來，如果專案達到該服務設定的預算，系統就會暫停適用服務。

  • 您可以在 Firebase 控制台的產品專屬資訊主頁，或中央「Usage and billing」(用量與帳單) 資訊主頁中監控用量。

確保 Firebase 專案和應用程式遵循最佳做法

無論您是單一開發人員或企業級團隊，都必須確保 Firebase 專案、應用程式和資源受到保護、安全無虞，並能隨著團隊變化而發展。

請記住，Firebase 專案其實只是啟用了 Firebase 服務和設定的 Google Cloud 專案。這表示 Google Cloud 建議的許多最佳做法也適用於 Firebase。

  • 為開發、測試和正式環境使用不同的 Firebase 專案。

    盡量避免與正式版應用程式相關聯的專案意外曝光。進一步瞭解如何設定開發工作流程。

  • 保護重要專案，尤其是與正式版應用程式相關聯的專案。

  • 如果您尚未設定 Google Cloud 組織，建議您設定一個，並將 Firebase 專案新增至該組織。

  • 為 Firebase 專案新增多位擁有者，尤其是專案不屬於 Google Cloud 機構時。進一步瞭解指派 Firebase 專案擁有者的時機和方式。

  • 以 Google 群組的形式新增專案成員 (又稱「主體」)，而非個別新增。

    使用群組可讓您更輕鬆地大量指派角色給團隊成員，以及管理誰有權存取 Firebase 專案，特別是在團隊成員輪替或離職時。

  • 為每位專案成員 (又稱「主體」) 授予適當的 Firebase 專案和資源存取權。詳情請參閱「使用 Firebase IAM 管理專案存取權」。

  • 請確保每位適用的專案成員 (又稱「主體」) 都設定偏好設定，以便接收特定產品或專案狀態 (例如帳單方案變更或配額限制) 的快訊。詳情請參閱「接收 Firebase 快訊」。

    您也可以視需要自訂專案的「重要聯絡人」，讓特定或額外的專案成員接收通知。這項功能特別實用，可確保除了專案擁有者以外，還有其他人能收到帳單、法律和產品異動通知。

  • 限制 Firebase API 金鑰，只用於金鑰 API 許可清單中的 API。此外，請參閱 Firebase 安全性檢查清單中關於 API 金鑰的資訊。

準備應用程式使用的特定服務

在正式環境中使用應用程式時，應用程式採用的每項產品和服務可能都有特定考量。

Firebase AI Logic

Google Analytics

App Check

  • 確認 Firebase 控制台專案設定中的團隊 ID 正確無誤。

  • 如果您尚未開始強制執行 Firebase App Check，請為所有支援這項功能的服務啟用。App Check 有助於確保只有實際應用程式可以存取後端服務和資源。

Authentication

  • 停用任何未使用的供應商 (尤其是匿名驗證)。

  • 如果應用程式使用「使用 Google 帳戶登入」功能，請自訂 OAuth 同意畫面。

  • 自訂Authentication 電子郵件傳送服務的網域和寄件者。

  • 如果您使用 Identity Platform 簡訊驗證服務，請開始強制執行 Firebase App Check，並設定簡訊區域政策，保護應用程式免受簡訊濫用行為影響。

  • 在 Apple 平台上，針對常見的 Authentication 錯誤導入錯誤處理機制。

  • 在 Firebase 控制台的「Project settings 」(專案設定) 中，為應用程式的簽署 憑證新增發布 SHA-1 雜湊。如果應用程式使用電話號碼登入或「使用 Google 帳戶登入」功能 (有 OAuth 用戶端需求)，則需要 SHA-1 雜湊。

  • 為網域新增存取控管機制，防止未經授權的使用行為。具體來說，請在 Firebase 控制台的 「Authentication」部分 中，允許存取正式版網域 (如果您使用的產品 依賴 Firebase Security Rules，這點尤為重要)。

Cloud Firestore

Cloud Messaging

  • 建議啟用 Cloud Messaging 資料匯出至 BigQuery 的功能，以便使用 BigQuery SQL 分析資料，或匯出資料並用於自己的工具。

  • 在 Firebase 控制台中，上傳 Apple 應用程式的 Cloud Messaging APNS 驗證金鑰。如果使用 APNS 憑證，請務必上傳正式版 APNS 憑證。

  • 建議為 Cloud Messaging 啟用 Cloud 稽核記錄，以便產生稽核記錄，記錄 Google Cloud 資源中的管理和存取活動。

  • 請務必定期更新至最新版 SDK，確保能使用新功能和安全性更新。

  • 在應用程式伺服器上，遵循Cloud Messaging註冊權杖管理最佳做法。儲存註冊權杖時，請加上時間戳記，並在權杖變更時更新，以及移除過時權杖 (閒置超過一個月)，確保傳送報表有效，並能有效指定訊息目標。

  • 遵循大量傳送 Cloud Messaging 訊息的最佳做法。請使用 HTTP v1 API 或 Firebase Admin SDK，實作指數輪詢和抖動機制來重試，並遵循 Retry-After 標頭，避免流量暴增和達到頻率限制。

Cloud Storage

Crashlytics

  • 請確認每位適用的專案成員 (又稱「主體」) 都已設定偏好設定，以便接收 Crashlytics 或專案狀態 (例如帳單方案變更或配額限制) 的快訊。詳情請參閱「接收 Firebase 快訊」。

  • 建議啟用 Crashlytics 資料匯出至 BigQuery 的功能，以便使用 BigQuery SQL 分析資料，或匯出資料並用於自己的工具。

  • (僅限原生 Android 和 iOS) 建議啟用 Crashlytics 中的 AI 輔助功能，加快瞭解當機原因和處理方式。

  • 上傳發布子版本的 dSYM 檔案，以便在 Crashlytics 中使用。確認 Xcode 能自動處理 dSYM 並上傳檔案。

  • 上傳發布子版本的 ProGuard 對應，以便在 Crashlytics 中使用。您可以使用 Firebase CLI 上傳。

  • 將 Firebase 連結至 Google Play，即可更全面地瞭解 Android 應用程式的健康狀態。舉例來說，您可以依 Google Play 測試群組篩選應用程式的當機報告，讓資訊主頁更專注於特定版本。

  • 如果建構作業指定 Android 並使用 IL2CPP，請務必為每個要取得符號的建構作業上傳原生符號，無論程式碼或設定是否有任何變更。

  • Dynamic Links 已淘汰，建議您停止使用這項服務。詳情請參閱淘汰常見問題。

Firebase ML

Performance Monitoring

Realtime Database

Remote Config

  • 確認任何實驗性Remote Config規則都不會影響版本使用者，且應用程式中已發布適當的伺服器和應用程式內預設值。

  • 建議您在 Remote Config 中設定 minimum_version 參數，以便在舊版應用程式不相容或淘汰時，提示或要求使用者更新應用程式。