通过

源代码管理仪表板

本文介绍如何使用 Databricks Git 文件夹进行版本控制和协作仪表板开发。 它还提供有关如何实现 CI/CD 过程以跨不同工作区开发和部署仪表板的指导。

重要

此功能目前以公共预览版提供。

概述

将 Databricks Git 文件夹用于仪表板可以更好地了解更改和历史记录，使协作更高效。 它还简化了将仪表板部署到生产环境，并使你能够恢复以前的版本，充当可靠的备份解决方案。

启用仪表板源代码管理

工作区管理员可以从 预览页面控制对公共预览版的工作区访问权限。 默认情况下， Git 文件夹预览中的支持仪表板 为 On。

Git 集成如何与仪表板配合使用

可以使用 Databricks Git 文件夹来跟踪和管理对草稿仪表板所做的更改。 跟踪仪表板中的所有更改都反映在仪表板草稿中。 不会跟踪发布和排程配置，例如仓库选择和日程创建。 若要管理这些配置，请使用 UI 或使用 Databricks 资产捆绑包或 AI/BI REST API 自动更改。 请参阅 仪表板 和 Lakeview REST API 参考。

注释

AI/BI 仪表板以前称为 Lakeview 仪表板。 Lakeview API 将保留该名称。

  • 若要了解有关使用捆绑包进行仪表板管理的详细信息，请参阅 仪表板。
  • 有关通过 REST API 发布和计划仪表板的详细信息，请参阅 Lakeview API 参考。

Databricks Git 文件夹提供了一种集中的方式来管理仪表板和其他工作区对象的常见 Git 操作。 若要了解详细信息，请参阅 Databricks Git 文件夹的 Git 集成。

将源代码管理应用于仪表板

若要使用 Git 跟踪仪表板，请将仪表板放置在 Databricks Git 文件夹中。 使用以下选项之一：

  • 新仪表板：在现有 Databricks Git 文件夹中创建仪表板，以从头开始应用源代码管理。
  • 现有仪表板：将现有仪表板移动到 Databricks Git 文件夹中，以便使用 Git 对其进行跟踪。

管理源代码管理的仪表板的权限

与其他工作区对象一样，在文件夹级别设置的权限适用于该文件夹中的所有对象。 Git 文件夹中的仪表板除了继承任何特定于仪表板的权限之外，还继承父文件夹的权限。 用户必须具有CAN_MANAGE权限才能执行大多数 Git 操作。 若要了解详细信息，请参阅 文件夹 ACL 和 Git 文件夹 ACL。

用户应将存储库克隆到自己的 Databricks Git 文件夹中，使用功能分支并提交拉取请求。 下表概述了在开发和部署的不同阶段使用 Git 文件夹管理仪表板的建议。

项目阶段 工作流 预期结果 已知限制
初始提交
  • 将仪表板移动到工作区中的 Git 文件夹中。
  • 提交并推送到远程 Git 存储库。
 仪表板现在在远程 Git 存储库中受源控制。
发展
  • 开发人员在单独的开发分支上创建 Git 文件夹，通常位于主文件夹中。
  • 将更改提交到开发分支。
  • 使用拉取请求将开发分支合并到主分支。
  • 开发人员可以独立工作。
  • 仪表板受版本控制。
 仪表板文件采用 JSON 格式。 SQL 查询显示为单行，这会使拉取请求中的差异难以查看。
部署
  • 使用者访问仪表板的一致的已发布版本。
  • 同一文件夹中的仪表板可以与不同的受众共享。
 没有内置支持将远程分支与工作区中的 Git 文件夹同步，或者通过远程仪表板资源部署 Databricks 资产捆绑包。 设置 CI/CD 自动化以自动执行：
  • 从远程存储库拉取更新。
  • 同步后发布仪表板。
  • 更新后部署 Databricks 资产捆绑包。

有关 Databricks Git 文件夹中协作的更多最佳做法，请参阅 Git 文件夹中的协作。

局限性

将源代码管理与 AI/BI 仪表板配合使用时，请考虑以下限制：

  • 最多可以在单个 Git 文件夹中提交 100 个仪表板。 可以在公共预览期间修改此限制。
  • 不支持基于 Git 的作业（例如引用 Git URL 而不是工作区资产 ID 或路径的作业）。
  • 仪表板序列化会生成长字符串，使得在拉取请求期间读取和查看差异变得困难。
  • 仪表板文件格式会定期更改，以包含新字段和其他改进。 在公共预览期间，这些更改可能在 Git 中显示为与用户发起的编辑无关的差异。