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 專案。

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

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

  • 使用專案鎖定，防止專案遭到意外刪除。

  • 在 Firebase 控制台中套用「Prod」標記，以便輕鬆識別正式環境。

• 如果您尚未設定 Google Cloud 組織，建議您設定並將 Firebase 專案加入其中。

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

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

  使用群組可更輕鬆地大量指派團隊成員的角色，以及管理哪些人有權存取 Firebase 專案，特別是團隊成員輪調或離職時。

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

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

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

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

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

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

Firebase AI Logic

• 請參閱「使用 Firebase AI Logic 的正式版檢查清單」。

Google Analytics

• 定義 Google Analytics 的目標對象條件，以便在應用程式推出後開始收集數據分析資料。

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

• 限制使用者屬性，只收集與整個應用程式生命週期相關的資訊。可建立的屬性數量有限，且無法封存。

• 查看 Google Analytics 資源和帳戶的Google Analytics角色設定。這些權限與 Firebase 專案 IAM 權限和角色分開管理。

• 確認 Firebase 控制台的「專案設定」中，App Store ID 和團隊 ID (如有必要) 正確無誤。

App Check

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

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

Authentication

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

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

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

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

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

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

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

Cloud Firestore

• 設定 Cloud Firestore Security Rules，防止非預期的資料存取。

• 在發布子版本中，使用 ProGuard 程式碼縮減。如果沒有 ProGuard，Cloud Firestore SDK 和其依附元件可能會增加 APK 大小。

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

• 設定 Cloud Storage Security Rules，防止非預期的資料存取。

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

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

Firebase ML

• 請參閱「準備發布 Apple 應用程式正式版Firebase ML」。

• 請參閱「準備發布 Android 應用程式正式版Firebase ML」。

Performance Monitoring

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

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

Realtime Database

• 設定 Realtime Database Security Rules，防止非預期的資料存取。

• 確認您已準備好擴大規模。Realtime Database 的預設配額足以應付大多數應用程式的需求，但部分應用程式可能需要額外容量。

• 設定 ProGuard 規則，以便與 Realtime Database 搭配使用。

Remote Config

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

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