在多數情況下,建議您使用 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 權限。
初始新手上路權限 (首次部署至某個位置)
首次在專案位置啟動本機來源部署作業時,App Hosting 必須佈建 GCS bucket 來儲存封存檔,並授予 App Hosting 服務代理存取權。由於這些是專案層級的管理工作,因此需要專案擁有者或 IAM 管理員權限。具備基本「編輯者」或「檢視者」角色的使用者無法執行這項初始設定,且會遭到封鎖。
必要設定權限包括:
- 啟用 Storage API:
serviceusage.services.enable - 建立來源 bucket:
storage.buckets.create和storage.buckets.list - 設定服務代理:
resourcemanager.projects.setIamPolicy授予 App Hosting 讀取權限 (roles/storage.objectViewer),以便在建構期間擷取上傳的程式碼。
初始部署時,GCS bucket 的生命週期為 30 天,之後就會刪除。不過,您可以在 Cloud 控制台管理這個時間範圍,方法是依序前往「Cloud Storage」->「Buckets」(值區) ->「Lifecycle」(生命週期) ->「Rules」(規則)。請參閱「管理物件生命週期」。
後續部署作業的權限 (位置初始化後)
為位置初始化來源 bucket 和角色繫結後 (透過初始 CLI 部署或控制台設定),一般開發人員、編輯者或App Hosting管理員即可部署更新。例行部署作業不需要專案層級的管理權限。
有效部署權限包括:
- 驗證 bucket:
storage.buckets.list - 上傳來源封存檔:
storage.objects.create - 觸發建構和推出作業:標準 App Hosting 權限 (
apphosting.builds.create和apphosting.rollouts.create)
使用 Firebase CLI 從來源部署
Firebase CLI 14.4.0 以上版本可讓您直接從本機電腦,將應用程式的原始碼和設定推送至 Firebase。如果您已管理其他 Firebase 部署作業 (例如安全性規則或函式),並想透過單一 CLI 指令同時部署網頁應用程式和後端服務,這項功能就非常實用。
必要條件
- 專案必須採用 Blaze 方案。
- 必須使用 firebase-tools 14.4.0 以上版本。
部署步驟
- 在本機專案目錄中執行
firebase init apphosting。 - 收到提示時,選取「Use an existing project」,然後選擇目標 Firebase 專案。
- 選取要部署至新的或現有的後端。這個步驟會為本機目錄設定 App Hosting 部署作業,並提示您輸入設定詳細資料:
- 要部署至的後端 ID
- 要部署至哪個區域 (如要建立新的後端)
- 應用程式程式碼根目錄的路徑
- 偏好的 Node.js 執行階段。選取特定版本的執行階段,即可啟用基本映像檔自動更新 (ABIU) 功能,自動為基礎環境套用安全性修補程式。
- 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:在初始後端新手上路流程中
- 選取來源:在後端建立精靈的「您想如何匯入應用程式?」步驟中,選取「上傳 ZIP 檔案」。
- 新手上路準備:點選「Next」會觸發背景準備流程,依序啟用 Storage API、確保設定正確的角色,以及 upsert bucket。UI 會顯示載入旋轉圖示,並顯示動態狀態訊息:「正在啟用 API...」、「Checking permissions...」(正在檢查權限...) 和「Preparing bucket...」(正在準備 bucket...)。
- 錯誤處理和防護措施:如果任何準備步驟失敗 (例如非擁有者因 IAM 權限不足而收到
403 PERMISSION_DENIED),UI 會顯示專屬警告,指示您與專案擁有者聯絡。在問題解決前,逐步操作導覽會嚴格鎖定,「Next」按鈕和最後的「Finish and Deploy」按鈕會保持停用狀態。
- 錯誤處理和防護措施:如果任何準備步驟失敗 (例如非擁有者因 IAM 權限不足而收到
- 上傳檔案:準備工作順利完成後,請選取封存檔案,或將檔案拖曳到檔案上傳工具元件。
Configure Settings:指定應用程式根目錄 (預設為
/)。按一下「Finish and Deploy」(完成並部署):上傳 ZIP 檔案時,獨立的「Finish」(完成) 按鈕會停用,因為上傳封存檔是一次性動作,且必須立即部署,才能確保後端正常運作。
方法 B:建立手動推出作業
- 開啟對話方塊:在 App Hosting 資訊主頁中,按一下「Create rollout」(建立推出作業)。
- 選取來源:在對話方塊的步驟中,選取「上傳 ZIP 檔案」。如果後端沒有現有的 GitHub 連線,系統會停用「GitHub」選項。
- 準備和上傳:選取後,系統會觸發相同的背景準備流程 (「正在啟用 API...」、「正在檢查權限...」和「正在準備 bucket...」)。成功後,使用上傳工具拖曳或選取封存檔案,指定「App root directory」(應用程式根目錄),然後按一下「Deploy」(部署),觸發建構和推出作業。
使用 Terraform 部署
如需進一步控管建構程序和部署環境,可以使用 Terraform 部署。Terraform 可讓您使用宣告式設定檔定義及管理 App Hosting 資源,並可直接將預先建構的容器映像檔部署至 App Hosting,而不必依賴 App Hosting 從原始碼建構。
如果您是第一次使用 Terraform,請參閱「開始使用 Terraform 和 Firebase」。如果您已熟悉 Terraform,可以開始使用設定檔範例和其他 App Hosting 資源。
設定 CI/CD 的 GitHub 連線
您隨時可以前往 Firebase 控制台,在後端設定的「Deployment」(部署作業) 分頁中連結 GitHub 存放區。這樣一來,您就能從本機環境部署應用程式原型,並在準備就緒時轉換至自動化 CI/CD 管道。
使用 AI 工具部署
Firebase Studio 將於 2027 年 3 月 22 日起停用。 雖然您的 App Hosting 後端不會受到影響,但 Firebase Studio 中的「Publish」(發布) 按鈕將會停用。如要繼續發布更新,而不變更網址,請遷移專案。瞭解如何遷移。