部署至 App Hosting 的其他方式

我們通常建議使用 自動推出或 手動觸發推出 ，Firebase不過，您可能需要更自訂的部署流程。App Hosting 提供多種自訂部署選項。

從來源部署

從來源部署可讓您將應用程式的原始碼和設定直接推送至 App Hosting，不需持續連線至 GitHub。

從來源部署時，App Hosting 會將原始碼上傳至 Google Cloud Storage bucket，在 Cloud Build 中執行架構的建構指令，並將編譯的構件部署至 Cloud Run 和 Cloud CDN。無論是從本機來源或 GitHub 部署，都使用相同的建構程序。如果專案中存在 .gitignore 檔案，系統會從部署作業中排除該檔案內列出的檔案和資料夾。

您可以使用 Firebase CLI 或 Firebase 控制台，從本機來源部署。

必要 IAM 權限和基礎架構設定

Firebase CLI 和 Firebase 控制台都使用相同的後端基礎架構來儲存及建構來源封存檔，因此兩種部署方法都適用相同的 IAM 權限規定。

確切需求取決於您是否首次部署至特定位置 (區域)。如要進一步瞭解權限，請參閱 Firebase IAM 總覽和特定 Firebase App Hosting 權限。

初始上線權限 (首次部署至某個地點)

首次在專案位置啟動本機來源部署作業時，Hosting 必須佈建 GCS 值區來儲存封存檔，並授予 Hosting 服務代理程式存取權。由於這些是專案層級的管理工作，因此需要專案擁有者或 IAM 管理員權限。具備基本「編輯者」或「檢視者」角色的使用者無法執行這項初始設定，且會遭到封鎖。

必要設定權限包括：

  • 啟用 Storage API：serviceusage.services.enable
  • 建立來源 bucket：storage.buckets.create 和 storage.buckets.list
  • 設定服務代理程式：resourcemanager.projects.setIamPolicy 授予Hosting讀取權限 (roles/storage.objectViewer)，以便在建構期間擷取上傳的程式碼。

在初始部署作業中，系統會建立生命週期為 30 天的 GCS bucket，之後會刪除該 bucket。不過，您可以在 Cloud 控制台的「Cloud Storage」->「Bucket」->「生命週期」->「規則」中管理這個時間範圍。請參閱「管理物件生命週期」。

後續部署作業的權限 (位置初始化後)

為位置初始化來源 bucket 和角色繫結後 (透過初始 CLI 部署或控制台設定)，一般開發人員、編輯者或 App Hosting管理員即可部署更新。日常部署作業不需要專案層級的管理權限。

有效部署權限包括：

  • 驗證值區：storage.buckets.list
  • 上傳來源封存檔：storage.objects.create
  • 觸發建構及推出作業：標準 Hosting 權限 (apphosting.builds.create 和 apphosting.rollouts.create)

使用 Firebase CLI 從來源部署

Firebase CLI 14.4.0 以上版本可讓您直接從本機將應用程式的原始碼和設定推送至 Firebase。如果您已管理其他 Firebase 部署作業 (例如安全防護規則或函式)，並想透過單一 CLI 指令一併部署網路應用程式和後端服務，這項功能就非常實用。

事前準備

  • 專案必須採用 Blaze 方案。
  • 您必須使用 firebase-tools 14.4.0 以上版本。

部署步驟

  1. 在本機專案目錄中執行 firebase init apphosting。
  2. 系統提示時，請選取「使用現有專案」，然後選擇目標 Firebase 專案。
  3. 選取要部署的新後端或現有後端；這個步驟會為本機目錄設定 Hosting 部署作業，並提示您輸入設定詳細資料：
    • 要部署的後端 ID
    • 如要建立新的後端，請指定部署區域
    • 應用程式程式碼根目錄的路徑
    • 偏好的 Node.js 執行階段。選取特定版本的執行階段後，系統會自動更新基本映像檔 (ABIU)，自動為基礎環境套用安全性修補程式。
  4. App Hosting 會將部署偏好設定儲存在 firebase.json 中，並在本機專案中建立檔案 (如果檔案不存在)。初始化作業順利完成後，請執行 firebase deploy 來部署原始碼。

firebase.json 範例

{
  "apphosting": [
    {
      "backendId": "my-backend",
      // rootDir specifies the directory containing the app to deploy, but the entire
      // parent directory of firebase.json will be zipped and uploaded to ensure that
      // dependencies outside of the app directory will be available at build time.
      "rootDir": "./my-app",
      "ignore": [
        "node_modules",
        ".git",
        "firebase-debug.log",
        "firebase-debug.*.log",
        "functions"
      ]
    }
  ]
}

透過 Firebase 控制台部署 (上傳 ZIP 檔案)

Firebase 控制台提供圖形介面，可直接上傳壓縮的來源封存檔來部署應用程式。如果您不想使用 GitHub，或偏好其他 CI/CD 設定，可以改用這種方式。

您可以在初始後端建立期間，或在現有後端建立手動推出作業時，執行封存上傳作業，包括最初使用 Firebase CLI 部署的後端。

支援的格式

控制台上傳工具會驗證並接受兩種壓縮封存格式：

  • .zip
  • .tgz

檔案上傳工具的說明文字會明確顯示這些格式。

部署步驟

方法 A：在初始後端新手上路流程中
  1. 選取來源：在後端建立精靈的「您想如何匯入應用程式？」步驟中，選取「上傳 ZIP 檔案」。
  2. 準備加入：按一下「下一步」會觸發背景準備流程，依序啟用 Storage API、確保已設定正確的角色，並插入/更新值區。使用者介面會顯示載入微調器，以及動態狀態訊息：「正在啟用 API...」「正在檢查權限...」和「正在準備 bucket...」。
    • 錯誤處理和防護措施：如果任何準備步驟失敗 (例如非擁有者因 IAM 權限不足而收到 403 PERMISSION_DENIED)，使用者介面會顯示專屬警告，指示您與專案擁有者聯絡。系統會嚴格鎖定步進導覽，且「下一步」按鈕和最終的「完成並部署」按鈕會保持停用，直到問題解決為止。
  3. 上傳檔案：準備作業順利完成後，請選取或將封存檔案拖曳至檔案上傳器元件。

  4. 設定：指定「應用程式根目錄」 (預設為 /)。

  5. 按一下「完成並部署」：上傳 ZIP 檔案時，「完成」按鈕會停用，因為上傳封存檔是一次性動作，且必須立即部署，才能確保後端正常運作。

方法 B：建立手動推出版本
  1. 開啟對話方塊：在 Hosting 資訊主頁中，按一下「建立推出版本」。
  2. 選取來源：在對話方塊的步進器中選取「上傳 ZIP 檔案」。如果後端沒有現有的 GitHub 連線，「GitHub」選項會停用。
  3. 準備與上傳：選取後會觸發相同的背景準備流程 (「啟用 API...」「正在檢查權限...」和「正在準備 bucket...」。成功後，請使用上傳工具拖曳或選取封存檔案，指定「應用程式根目錄」，然後按一下「部署」，觸發建構及推出程序。

使用 Terraform 部署

如要進一步控管建構程序和部署環境，可以使用 Terraform 進行部署。Terraform 可讓您使用宣告式設定檔定義及管理 App Hosting 資源，並提供直接將預先建構的容器映像檔部署至 App Hosting 的功能，不必依賴 App Hosting 從原始碼建構。

如果您是 Terraform 新手，請參閱「開始使用 Terraform 和 Firebase」。如果您已熟悉 Terraform，可以從範例設定檔和其他 App Hosting 資源著手。

設定 GitHub 連線以進行 CI/CD

您隨時可以在 Firebase 控制台的後端設定中，前往「部署」分頁連結 GitHub 存放區。這可讓您從本機環境部署應用程式原型，然後在準備就緒時轉換為自動化 CI/CD 管道。

使用 AI 工具部署

我們將於 2027 年 3 月 22 日停用Firebase Studio。 您的App Hosting後端不會受到影響，但 Firebase Studio 中的「發布」按鈕將會停用。如要繼續發布更新，且不變更網址，請遷移專案。瞭解如何遷移。