dbt Projects on Snowflake 上的 CI/CD 集成

dbt 项目对象支持使用 Snowflake CLI 命令将部署和执行集成到 CI/CD 工作流程中。

本主题介绍如何使用 GitHub 操作，在您每次开启拉取请求或合并到主分支时自动测试并部署您的 dbt Projects on Snowflake。

持续集成 (CI) 会在每次拉取请求时针对开发架构运行您的 dbt 项目。换句话说，每当有人在您的代码库中开启或更新拉取请求时，您都会自动对新代码运行测试和构建。这有助于在合并之前尽早发现问题。

持续部署 (CD) 会在您的提交合并后保持 Snowflake 中的 dbt 项目对象为最新。换句话说，每当代码合并到分支中时，您都会自动将更新后的代码部署到生产环境。这确保了您的生产环境能够可靠且可复现地保持最新状态。

CI/CD 有助于避免容易出错的手动部署，确保变更在合并前得到验证，并实现一致、可重复的部署和版本控制。

为什么为 dbt 项目使用 CI/CD

dbt 项目在代码中定义了所有数据转换，因此频繁的更新很容易引入错误。CI 通过在合并前在独立的开发环境中测试每次变更，从而尽早发现这些问题。

变更合并后，CD 会自动更新 Snowflake 生产环境中的官方 dbt 项目对象。这消除了手动步骤，降低了风险，使所有内容都处于版本控制之下，并支持可靠的协作工作流。

在 dbt 项目上使用 CI/CD 的高级先决条件

  • 存储在 Git 库中的 dbt 项目（例如 GitHub）。

  • 具有如 Snowflake 上 dbt 项目的访问控制 中所述权限的 Snowflake 账户和用户。

  • 创建和编辑以下对象的权限或管理员的访问权限，管理员可以代表您创建每个对象：

    • 用于保存 Snowflake 账户、数据库和架构值的 GitHub 库环境变量和密钥，以及定义 CI 和 CD 作业的工作流文件（例如 .github/workflows/…）。

    • 用于与 GitHub 通信的 Snowflake 服务账户

  • Snowflake 中开发环境（用于 CI）和生产环境（用于 CD）的分离（例如，为每个环境设置独立的数据库或架构）。

  • 允许您的 CI/CD 运行器（例如 GitHub Actions）连接到 Snowflake 的方式，例如 OIDC 或 PAT。有关更多信息，请参阅 在 CI/CD 工作流程中安全地配置该 Action。

  • 在您的代码库中，配置一个指向开发和生产目标（例如数据库/架构、仓库）的 profiles.yml 文件。

  • 允许从您的 Git 提供商入站访问 Snowflake 的网络策略。

CI/CD 工作流概览

以下步骤概述了使用 CI/CD 的典型工作流。有关详细教程，请参阅 教程：在 dbt Projects on Snowflake 上设置 CI/CD 集成。

  1. 开发者在分支中编写或修改 dbt 代码（模型、测试等）。

  2. 开发者开启一个拉取请求。

  3. CI 启动：dbt 项目对象的测试实例被部署到 Snowflake 开发环境，并运行 dbt run 和 dbt test 命令。

    • 如果操作失败，则拉取请求失败。开发者必须修复并更新，然后重新运行。

    • 如果所有操作都通过，则拉取请求符合合并条件。

  4. 拉取请求合并到主分支。

  5. CD 启动：Snowflake 中的生产 dbt 项目对象被更新以反映最新代码。

  6. （可选）可以部署自动调度（例如通过 Snowflake 任务），以便数据管道按计划运行而无需人工干预。

语言: 中文