部署到 App Hosting 的其他方式

在大多数情况下，我们建议您使用 Firebase 控制台中的自动发布或手动触发的发布。不过，您可能需要使用更自定义的部署流程。App Hosting 提供了多个自定义部署选项。

从源代码部署

通过从源代码部署，您可以将应用的源代码和配置直接推送到 App Hosting，而无需建立持久的 GitHub 连接。

从源代码部署时，App Hosting 会将源代码上传到 Google Cloud Storage 存储桶，在 Cloud Build 中运行框架的构建命令，并将编译后的工件部署到 Cloud Run 和 Cloud CDN。本地源代码部署与 GitHub 部署使用相同的构建过程。如果项目中存在 .gitignore 文件，则其中列出的文件和文件夹将从部署中排除。

您可以使用 Firebase CLI 或 Firebase 控制台从本地源代码进行部署。

所需的 IAM 权限和基础架构设置

由于 Firebase CLI 和 Firebase 控制台都使用相同的后端基础架构来存储和构建源代码归档，因此这两种部署方法具有相同的 IAM 权限要求。

具体要求取决于您是否是首次部署到特定位置（区域）。如需详细了解权限，请参阅 Firebase IAM 概览和特定的 Firebase App Hosting 权限。

初始配置（首次部署到某个位置）所需的权限

首次在项目位置启动本地源代码部署时，App Hosting 必须预配一个 GCS 存储桶来存储您的归档，并向 App Hosting 服务代理授予访问权限。由于这些是项目级管理任务，因此需要 Project Owner 或 IAM Admin 权限。拥有基本 Editor 或 Viewer 角色的用户无法执行此初始设置，并且会被阻止。

前提设置权限包括：

  • 启用 Storage API：serviceusage.services.enable
  • 创建来源存储桶：storage.buckets.create 和 storage.buckets.list
  • 配置服务代理：resourcemanager.projects.setIamPolicy，以向 App Hosting 授予读取权限 (roles/storage.objectViewer)，使其能够在构建期间提取上传的代码。

对于初始部署，GCS 存储桶的生命周期为 30 天，之后该存储桶将被删除。不过，您可以在 Cloud 控制台中的 Cloud Storage -> 存储桶 -> 生命周期 -> 规则中管理此时间范围。请参阅管理对象生命周期。

后续部署的权限（在位置信息初始化后）

为某个位置初始化源存储桶和角色绑定后（通过初始 CLI 部署或控制台设置），常规开发者、编辑者或 App Hosting 管理员便可以部署更新。日常部署不需要项目级管理权限。

有效部署权限包括：

  • 验证存储桶：storage.buckets.list
  • 上传源代码归档：storage.objects.create
  • 触发构建和发布：标准 App Hosting 权限（apphosting.builds.create 和 apphosting.rollouts.create）

使用 Firebase CLI 从源代码进行部署

借助 Firebase CLI v14.4.0 及更高版本，您可以直接将应用的源代码和配置从本地机器推送到 Firebase。如果您已经管理其他 Firebase 部署（例如安全规则或函数），并且希望通过单个 CLI 命令同时部署 Web 应用和后端服务，那么这种方法会非常方便。

前提条件

  • 您的项目必须采用 Blaze 方案。
  • 您必须运行 firebase-tools 14.4.0 版或更高版本。

部署步骤

  1. 在本地项目目录中运行 firebase init apphosting。
  2. 出现提示时，选择使用现有项目，然后选择目标 Firebase 项目。
  3. 选择要部署到的新后端或现有后端；此步骤会为您的本地目录设置 App 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 设置，则可以采用此方法来替代 GitHub 连接流程。

您可以在初始后端创建期间或在现有后端（包括最初使用 Firebase CLI 部署的后端）上创建手动发布时执行归档上传。

支持的格式

控制台上传工具原生验证并接受两种压缩归档格式：

  • .zip
  • .tgz

这些格式会在文件上传器的说明文本中明确显示。

部署步骤

方案 A：在初始后端配置期间
  1. 选择来源：在后端创建向导中，在“您想如何导入应用？”步骤中选择上传 ZIP 文件。
  2. 准备启用：点击“下一步”会触发后台准备流程，该流程会依次启用 Storage API、确保设置正确的角色，并对存储桶执行 upsert 操作。界面会显示一个加载旋转图标，并显示动态状态消息：“正在启用 API…”“正在检查权限…”和“正在准备存储桶…”。
    • 错误处理和安全措施：如果任何准备步骤失败（例如，非 Project Owner 因 IAM 权限不足而收到 403 PERMISSION_DENIED），界面会显示一条专用警告，指示您与 Project Owner 联系。分步导航功能会被严格锁定，并且“下一步”按钮和最终的“完成并部署”按钮会保持停用状态，直到问题得到解决。
  3. 上传文件：准备工作成功完成后，选择归档文件或将其拖动到文件上传器组件中。

  4. 配置设置：指定应用根目录（默认为 /）。

  5. 点击完成并部署：对于 ZIP 上传，独立的“完成”按钮处于停用状态，因为上传归档是一次性操作，必须立即进行部署，以确保后端正常运行。

选项 B：创建手动发布
  1. 打开对话框：在 App Hosting 信息中心内，点击创建发布。
  2. 选择来源：在对话框的步骤中选择上传 ZIP 文件。如果后端没有现有的 GitHub 连接，则“GitHub”选项处于停用状态。
  3. 准备和上传：选择后会触发相同的后台准备流程（“正在启用 API…”、“正在检查权限…”和“正在准备存储桶…”）。成功后，使用上传器拖动或选择归档文件，指定应用根目录，然后点击部署以触发构建和发布。

使用 Terraform 进行部署

如果您需要更好地控制构建过程和部署的环境，可以使用 Terraform 进行部署。借助 Terraform，您可以使用声明式配置文件定义和管理 App Hosting 资源，并能够将自己的预构建容器映像直接部署到 App Hosting，而无需依赖 App Hosting 从源代码进行构建。

如果您刚开始使用 Terraform，请参阅使用入门：将 Terraform 与 Firebase 搭配使用。 如果您已经熟悉 Terraform，则可以开始使用示例配置文件和其他 App Hosting 资源。

为 CI/CD 设置 GitHub 连接

您可以随时在 Firebase 控制台中后端设置的部署标签页中连接 GitHub 代码库。这样，您就可以从本地环境部署应用原型，然后在准备就绪后过渡到自动化 CI/CD 流水线。

使用 AI 工具进行部署

我们将于 2027 年 3 月 22 日弃用 Firebase Studio。 虽然您的 App Hosting 后端不受影响，但 Firebase Studio 中的发布按钮将被停用。如需继续发布更新而不更改网址，请迁移您的项目。 了解如何迁移。