Looker CI/CD 使用和工作流

本页介绍了在安装和配置 CI/CD 工作流后,如何在 Looker 中使用此类工作流。

这些说明使用由开发、质量检查和制作组成的三层式系统。不过,您可以将相同的原则应用于两层或四层系统。

以下说明还假定使用 GitHub 作为 Git 提供商。您可以使用其他 Git 提供商来创建 CI/CD 工作流;但是,您必须具备为提供商修改这些说明的专业知识。

工作流概览

LookML 开发者首先在开发分支(通常命名为 dev-my-user-ydnv)中编写代码,使用 Spectacles 测试更改,然后提交代码。最后,他们打开一个拉取请求,将其代码与 main 分支合并。

打开拉取请求后,开发者会进入 GitHub。开发者应使用传统提交风格编写富有意义的 PR 标题,并在说明中添加将包含在变更日志中的评论。眼镜测试的结果应作为注释添加到 PR。

接下来,开发者应在 GitHub 中选择一个审核者。审核者会收到通知,并可以在公关中添加自己的评价。如果审核员批准了更改,系统会将 PR 与 main 分支合并。已调用 Webhook,现在开发环境已注意到这一变化。

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

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

为版本编号和命名提交内容的最佳实践

您可以使用您环境中适用的任何方式为版本及其关联的标记命名和编号。不过,此处使用了语义版本控制,强烈建议您也采用这种方法,因为它与 Release Please 插件配合得非常好。

在语义版本控制中,版本由三个数字组成,数字以句点分隔:MAJOR.MINOR.PATCH

  • 每次有版本修复 bug 时,PATCH 都会递增
  • 每次发布版本添加或优化功能并保持向后兼容时,MINOR 都会递增,而 PATCH 会重置为零
  • 添加向后兼容的功能时,MAJOR 会递增,并且 MINORPATCH 均会设为零

传统提交是一种按提交对最终用户的影响来命名提交的系统。虽然并非强制性要求,但使用传统的提交命名方式对 Release Please 插件也很有用。

在传统的提交命名中,每个提交消息都带有表示更改范围的指示符:

  • fix: 表示 bug 修复,例如 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。“发布请”插件甚至可以生成 CHANGELOG 文件并自动标记其发布。

使用高级部署模式

在开发实例上进行更改并作为 PR 提交后,Release Please 插件会使用版本标记(例如 v1.2.3)标记更改。然后,Looker 的高级部署模式会在 Looker 界面中将这些版本提供给质量检查实例和生产实例。

如需部署更改,请从 Looker IDE 中选择 Deployment Manager:

IDE 中的 Looker Deployment Manager 位置。

点击部署管理器右上角的选择提交链接。接下来,选择与要部署的代码相关联的三点状菜单,然后选择部署到环境

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

您无需再次为部署添加标记,因此请选择部署而不添加标记,然后按部署到环境按钮:

可在不使用标记的情况下进行部署的 Looker Deployment Manager 界面。

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

使用 Spectacles

每个开发者都可以使用 Spectacles 在更改仍位于开发分支中时进行验证。Spectacles 提供了四种不同的验证程序:

当开发者提交拉取请求时,最好运行这些测试,并将结果复制到 PR 中的评论中。

SQL 验证器

SQL 验证器会测试每个探索,以确保 LookML 视图中定义的所有字段都与数据库中的实际 SQL 列或有效 SQL 表达式相对应。系统会调用 SQL 验证器,如下所示:

$ spectacles sql --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

例如:

$ spectacles sql --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0

=================== Testing 1/1 explores [concurrency = 10] ===================

✓ thelook_cicd.users passed

Completed SQL validation in 1 minute and 7 seconds.

LookML 验证器

LookML 验证器可确保 LookML 更改有效且没有语法错误。其调用方式如下所示:

$ spectacles lookml --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --branch DEV_BRANCH_NAME

例如:

$ spectacles lookml --config-file config-dev.yaml \
    --project thelook_cicd \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0

============= Validating LookML in project thelook_cicd [warning] ==============

✗ thelook_cicd/business_pulse.dashboard.lookml failed
✗ thelook_cicd/thelook_cicd.model.lkml failed

================ thelook_cicd/business_pulse.dashboard.lookml:28 ===============

[Error] Unknown field "users.state" in explore "users" for field_filter.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/business_pulse.dashboard.lookml?line=28

================ thelook_cicd/business_pulse.dashboard.lookml:36 ===============

[Warning] Unknown field "users.state" (for explore "orders" in model
"thelook_cicd") referenced in dashboard element.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/business_pulse.dashboard.lookml?line=36

[Additional errors snipped]

Completed validation in 6 seconds.

内容验证器

内容验证器会测试在进行更改后,外观和用户定义的信息中心 (UDD) 等任何已保存的内容是否仍能正常运行。为了加快作业的运行速度并提供可管理的结果,系统仅对根据您指定的探索生成的内容进行验证。内容验证器的调用方式如下:

$ spectacles content --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

例如:

$ spectacles content --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0
Building LookML project hierarchy for project 'thelook_cicd' @ dev-my-user-ydnv

==================== Validating content based on 5 explores ====================

✗ thelook_cicd.users failed

================= test dashboard for spectacles [TheLook_CICD] =================

Tile 'test dashboard for spectacles' failed validation.

Error in thelook_cicd/users: Unknown field "users.state".

Dashboard: https://gcpl2318.cloud.looker.com/dashboards/223

========================= Business Pulse [TheLook_CICD] ========================

Filter 'State / Region' failed validation.

Error in thelook_cicd/users: Unknown field "users.state".

Dashboard: https://gcpl2318.cloud.looker.com/dashboards/190

Completed content validation in 27 seconds.

断言验证

断言验证会测试您添加到 LookML 中的数据断言,以确保数据能够正确读取。例如,您的 LookML 中的数据测试可能如下所示:

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

调用断言验证,如下所示:

$ spectacles assert --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

例如:

$ spectacles assert --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0
Building LookML project hierarchy for project 'thelook_cicd' @ dev-my-user-ydnv

==================== Running data tests based on 1 explore =====================

✗ thelook_cicd.users failed

================ thelook_cicd/users/california_users_is_accurate ===============

Unknown filter field "users.state" in lookml test "california_users_is_accurate"
declaration.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

================ thelook_cicd/users/california_users_is_accurate ===============

Invalid filter: users.state

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

================ thelook_cicd/users/california_users_is_accurate ===============

Assertion "count_is_expected_value" failed: expression evaluated to "No".

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

Completed data test validation in 14 seconds.

默认情况下,我们会为数据洞见和信息中心分配递增的数字 ID,这些 ID 会在数据洞见或信息中心的网址中使用。不过,无法让这些内容在不同系统之间保持同步。因此,开发环境中特定信息中心的网址不会指向质量检查环境或生产环境中相同的信息中心。

对于 UDD,可以选择在网址中使用 slug(而非 ID)。Slug 是一组半随机的字符,而不是数字。可以在导入过程中设置 Slug,以便在开发、质量检查和制作阶段使用类似的网址指向同一个 UDD。最佳实践是使用短标签,而不是 ID,尤其是从“外观”或其他 UDD 中“点击进入”某个 UDD 时。

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

使用 Gazer 迁移用户内容

在制作、质量检查和制作之间复制 Look 和信息中心等内容通常很有用。您可能需要制作内容来展示新增的 LookML 功能,或者确保已保存的内容在 LookML 发生更改后仍能正常运行。在这些情况下,可以使用 Gazer 在实例之间复制内容。

LookML 信息中心

在常规 LookML CI/CD 工作流中,LookML 信息中心会在实例之间同步。不过,如果任何 UDD 已与 LookML 信息中心同步,则可以通过以下命令使用 Gazer 对其进行更新:

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

外观迁移与 UDD 迁移的工作原理非常相似。首先,使用 Gazer 将外观配置保存到 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