部署到 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 权限。

初始启用时的权限（首次部署到某个位置）

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

前提设置权限包括：

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

对于初始部署，GCS 存储分区的生命周期为 30 天，之后存储分区会被删除。不过，您可以在 Cloud 控制台中管理此时间范围，具体方法是依次前往 Cloud Storage -> 存储分区 -> 生命周期 -> 规则。请参阅管理对象生命周期。

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

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

有效部署权限包括：

  • 验证存储分区：storage.buckets.list
  • 上传源归档文件：storage.objects.create
  • 触发构建和发布：标准 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. 选择要部署到的新后端或现有后端；此步骤会为您的本地目录设置 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、确保设置正确的角色并更新存储分区。界面会显示一个带有动态状态消息的加载微调器：“正在启用 API…”“正在检查权限…”和“正在准备存储分区…”。
    • 错误处理和安全措施：如果任何准备步骤失败（例如，非 Project Owner 因 IAM 权限不足而收到 403 PERMISSION_DENIED），界面会显示一条专用警告，指示您与 Project Owner 联系。步进器导航严格锁定，并且“下一步”按钮和最终的“完成并部署”按钮在问题解决之前保持停用状态。
  3. 上传文件：准备工作成功完成后，选择或将归档文件拖动到文件上传器组件中。

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

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

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

使用 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 中的发布按钮将被弃用。如需继续发布更新而不更改网址，请迁移您的项目。 了解如何迁移。