Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

多层级 Looker CI/CD 用法和工作流

本页面介绍了如何在 Looker 中使用多层级 CI/CD 工作流（在安装和配置此类工作流后）。

这些说明使用包含开发、质量检查和生产的三层系统。不过，您可以将相同的原则应用于双层或四层系统。

这些说明还假设您使用 GitHub 作为 Git 提供方。您可以使用其他 Git 提供商来创建 CI/CD 工作流；不过，您必须具备相关专业知识，才能根据您的提供商修改这些说明。

工作流概览

LookML 开发者首先在其开发分支（通常命名为 dev-my-user-ydnv）中编写代码，然后使用 Looker 持续集成（或通过手动运行 CI 套件）测试其更改，并提交代码。最后，他们打开一个拉取请求，以将其代码与 main 分支合并。

当拉取请求打开时，开发者会转到 GitHub。开发者应使用常规提交样式编写有意义的 PR 标题，并在说明中添加将包含在更改日志中的注释。如果配置了拉取请求触发，Looker 持续集成会自动验证拉取请求，开发者可以在 Looker 或 GitHub 中查看结果。

接下来，开发者应在 GitHub 中选择审核者。审核者会收到通知，并可向 PR 添加审核意见。如果审核者批准了更改，则 PR 会与 main 分支合并。系统会调用 WebHook，开发环境现在会看到相应更改。

Release Please 自动化操作会自动运行，并打开第二个 PR 以创建新的带标记的版本。或者，如果已为此目的打开 PR，Release Please 会更新该 PR。发布 PR 具有关联的版本号，以及包含所含更改的标题和说明的更改日志。

当 Release Please 生成的 PR 获得批准并合并后，系统会生成新的版本标记，并将更改日志与 main 分支合并。Looker 的 QA 实例和正式版实例可以使用高级部署模式选择此版本。

有关版本编号和提交命名方面的最佳实践

您可以根据自己的环境，以任何有意义的方式命名和编号版本及其关联的标记。不过，此处使用的是语义版本控制，强烈建议您使用此方法，因为它与 Release Please 插件搭配使用效果很好。

在语义化版本控制中，版本由三个用英文句点分隔的数字组成：MAJOR.MINOR.PATCH

每次发布版本修复 bug 时，PATCH 都会递增
每次发布在向后兼容的同时添加或改进功能时，MINOR 都会递增，而 PATCH 会重置为零
添加不向后兼容的功能时，MAJOR 会递增，而 MINOR 和 PATCH 均设置为零

常规提交是一种根据提交对最终用户的影响来命名提交的系统。虽然不是必需的，但使用常规提交命名对于 Release Please 插件也很有用。

在常规提交命名中，每个提交消息都以更改范围的指示符开头：

bug 修复以 fix: 表示，例如 fix: set proper currency symbol on sale_amt format
新功能会用 feat: 表示，例如 feat: added explore for sales by territory
具有重大变更的功能会以 feat!: 表示，例如 feat!: rewrote sales explore to use the new calendar view
如果文档已更新，但 LookML 未更改，提交消息以 doc: 开头

如果始终使用常规提交，那么确定接下来要使用的语义版本号通常很简单。如果提交日志仅包含 fix: 和 doc: 提交，则应递增 PATCH。如果存在 feat: 提交，则应递增 MINOR。如果存在 feat!:，则应递增 MAJOR。Release Please 插件甚至可以自动生成 CHANGELOG 文件并标记版本。

使用高级部署模式

在开发实例上以 PR 形式提交更改后，Release Please 插件会使用 v1.2.3 等版本标记来标记更改。然后，Looker 的高级部署模式会在 Looker 界面中提供这些版本，以供质量检查和生产实例使用。

如需部署更改，请从 Looker IDE 中选择 Deployment Manager：

IDE 中的 Looker Deployment Manager 位置。

点击 Deployment Manager 右上角的 Select Commit 链接。接下来，选择与要部署的代码相关联的三点状菜单，然后选择部署到环境：

用于部署到环境的 Looker Deployment Manager 界面。

您无需再次标记部署，因此请选择不标记即部署，然后按部署到环境按钮：

用于在不添加标记的情况下进行部署的 Looker Deployment Manager 界面。

最后，使用 Deployment Manager 推送到生产环境。

使用 Looker 持续集成

为了验证开发分支中的更改或拉取请求中的更改，开发者可以使用 Looker 持续集成。持续集成提供了以下验证器：

SQL 验证器 - 验证探索中的维度是否能针对数据库正确运行。
断言验证器 - 运行 Looker 开发者创建的所有 LookML 数据测试，并返回所有失败和错误。
内容验证器 - 运行 Looker 内容验证，以测试 LookML 项目中的 Look 和信息中心是否存在错误。
LookML 验证器 - 运行 LookML 验证器以测试项目中的 LookML 错误。
样式验证器 - 在整个项目中强制执行 LookML 编码标准、命名惯例和结构最佳实践。

您可以将这些验证器分组到持续集成套件中，并在收到拉取请求时、按预定时间或手动自动运行它们。

SQL 验证器

持续集成 SQL 验证器会验证探索中的维度是否能针对您的数据库正常运行。它会测试 LookML 视图中定义的字段是否与数据库中的有效 SQL 列或表达式相对应。

SQL 验证器具有以下关键功能：

运行带有 LIMIT 0 和 WHERE 1=2 子句的查询来验证 SQL，而不会产生数据扫描费用。
支持增量验证，仅测试开发分支中发生更改的探索。
将范围验证限定为要查询的特定探索或排除的特定探索。
使用 LookML 标记或 SQL 注释（tags: ["ci: ignore"] 或 -- ci: ignore）从验证中排除特定维度。

如需了解详情和配置选项，请参阅持续集成 SQL 验证器文档页面。

LookML 验证器

持续集成 LookML 验证器会检查 LookML 项目是否存在语法错误，例如缺少括号或字段引用无效。对于在 Looker IDE 之外编写 LookML 的开发者，此验证器尤其有用。

LookML 验证器具有以下主要功能：

可让您设置严重程度阈值（错误、警告或信息），以确定哪些消息严重程度会导致运行失败。
可让您为验证运行配置超时时长。

如需了解详情和配置选项，请参阅持续集成 LookML 验证器文档页面。

内容验证器

持续集成内容验证器可验证在 LookML 更改后，保存的内容（例如 Look 和用户定义的信息中心 [UDD]）是否仍能正常运行。

内容验证器具有以下主要功能：

将范围验证限制为特定内容文件夹或探索。
排除个人文件夹中的内容。
支持增量验证，以查找开发分支独有的错误。

如需了解详情和配置选项，请参阅持续集成内容验证器文档页面。

断言验证器

持续集成断言验证器会运行项目中定义的 LookML 数据测试，以验证模型逻辑和数据完整性。

例如，LookML 数据测试可能如下所示：

test: historic_revenue_is_accurate {
  explore_source: orders {
    column: total_revenue { field: orders.total_revenue }
    filters: [orders.created_date: "2024"]
  }
  assert: revenue_is_expected_value {
    expression: ${orders.total_revenue} = 626000 ;;
  }
}

Assert Validator 具有以下关键功能：

范围可用于断言验证，以查询或排除特定探索。
可让您配置查询并发性，以管理数据库负载。

如需了解详情和配置选项，请参阅持续集成断言验证器文档页面。

管理和运行 CI 套件

如需管理和运行持续集成测试，请按以下步骤操作：

创建测试套件：在 Looker IDE 的测试套件页面上，配置要运行的验证器并设置其选项。如需了解详情，请参阅创建持续集成套件文档页面。
触发运行：在拉取请求上、按时间表或手动为开发分支或生产环境自动触发验证运行。如需了解详情，请参阅运行持续集成套件文档页面。
查看结果：在 CI 运行结果页面上查看错误消息、受影响的 LookML 行以及指向探索和信息中心的链接。如需了解详情，请参阅查看 CI 运行的结果文档页面。

Look 和信息中心的链接稳定性

默认情况下，系统会为 Look 和信息中心分配升序数字 ID，这些 ID 会用于 Look 或信息中心的网址中。不过，无法在不同系统之间保持这些设置同步。因此，开发中的特定信息中心的网址不会指向质量检查或生产环境中的同一信息中心。

对于 UDD，可以选择使用别名而不是 ID 作为网址的一部分。该标识名是一组半随机字符，而不是数字。Slug 可在导入时设置，这样一来，相似的网址便可在开发、QA 和生产环境中指向同一 UDD。使用 Slug 而不是 ID 是一种最佳实践，尤其是在从 Look 或其他 UDD“点击进入”UDD 时。

您可以通过检查 gzr dashboard cat 的输出内容来找到 slug。Slug 可在信息中心网址中代替数字 ID 使用。

使用 Gazer 迁移用户内容

在开发、QA 和生产环境之间复制 Look 和信息中心等内容通常很有用。您可能需要制作展示新 LookML 添加项的内容，或者验证保存的内容在 LookML 更改后是否仍能正常运行。在这些情况下，可以使用 Gazer 在实例之间复制内容。

LookML 信息中心

在常规 LookML CI/CD 工作流期间，LookML 信息中心会在实例之间同步。不过，如果任何 UDD 与 LookML 信息中心同步，则可以使用以下命令通过 Gazer 更新这些 UDD：

gzr dashboard sync_lookml DASHBOARD_ID --host TARGET_SYSTEM_URL

用户定义的信息中心

通过引用信息中心的 ID 和 UDD 所在的 Looker 实例的网址，可以使用 Gazer 迁移用户定义的信息中心 (UDD)。Gazer 会将信息中心配置保存到 JSON 文件，然后将该文件导入到目标 Looker 实例。

用于提取 UDD 配置的命令如下所示：

gzr dashboard cat DASHBOARD_ID --host TARGET_SYSTEM_URL --dir .

这将生成一个名为 Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json 的文件，其中包含信息中心的配置。

可以使用以下命令将 UDD 导入到目标系统：

gzr dashboard import Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json FOLDER_ID \
    --host TARGET_SYSTEM_URL

Look

Look 迁移的工作方式与 UDD 迁移非常相似。首先，使用 Gazer 将 Look 配置保存到 JSON 文件：

gzr look cat LOOK_ID --host SOURCE_SYSTEM_URL --dir .

然后，将 Look 导入目标实例：

gzr look import Look_LOOK_ID_LOOK_NAME.json FOLDER_ID \
    --host TARGET_SYSTEM_URL