本页面介绍如何在 安装和配置 CI/CD 工作流后在 Looker 中使用该工作流。
这些说明使用包含开发、质量检查和生产环境的三层系统。不过,您可以将相同的原则应用于两层或四层系统。
这些说明还假设您使用 GitHub 作为 Git 提供方。您 可以 使用其他 Git 提供方来创建 CI/CD 工作流;不过,您必须具备修改这些说明以适应您的提供方的专业知识。
工作流概览
LookML 开发者首先在其开发分支(通常命名为 dev-my-user-ydnv 之类的名称)中编写代码,使用 Spectacles 测试其更改,然后提交代码。最后,他们打开拉取请求,以将其代码与 main 分支合并。
打开拉取请求后,开发者会进入 GitHub。开发者应使用常规提交样式编写有意义的 PR 标题,并在说明中添加将包含在更改日志中的评论。Spectacles 测试的结果应作为评论添加到 PR 中。
接下来,开发者应在 GitHub 中选择审核者。审核者将收到通知,并可以将审核意见添加到 PR 中。如果审核者批准更改,PR 将与
main 分支合并。系统会调用 WebHook,开发环境现在会看到更改。
Release Please 自动化功能会自动运行并打开第二个 PR,以创建新的带标记的版本。或者,如果已为此目的打开 PR,Release Please 会更新该 PR。版本 PR 具有关联的版本号,以及包含所含更改的标题和说明的更改日志。
当 Release Please 生成的 PR 获得批准并合并后,系统会生成新的版本标记,并且更改日志会与 main 分支合并。Looker 的质量检查和生产实例可以使用高级部署模式选择此版本。
为版本编号和提交命名时的最佳实践
您可以根据环境的实际情况,以任何有意义的方式命名版本及其关联的标记。不过,此处使用的是语义版本控制,强烈建议您使用这种方式,因为它与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:

点击 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.
内容验证器
内容验证器会测试任何已保存的内容(例如 Look 和用户定义的信息中心 (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.
Look 和信息中心的链接稳定性
默认情况下,系统会为 Look 和信息中心分配升序数字 ID,这些 ID 会在 Look 或信息中心的网址中使用。不过,无法在不同系统之间保持这些 ID 同步。因此,开发环境中的特定信息中心的网址不会指向质量检查或生产环境中的同一信息中心。
对于 UDD,您可以选择使用 slug 而不是 ID 作为网址的一部分。slug 是一组半随机字符,而不是数字。处理后标题可以在导入时设置,以便类似的网址可以指向开发、质量保证和生产环境中的同一 UDD。使用 slug 而不是 ID 是一种最佳实践,尤其是在从 Look 或其他 UDD“点击进入”UDD 时。
您可以通过检查 gzr dashboard cat 的输出来找到 slug。您可以在信息中心网址中使用 slug 而不是数字 ID。
使用 Gazer 迁移用户内容
在开发、质量检查和生产环境之间复制 Look 和信息中心等内容通常很有用。您可能需要生成展示新 LookML 添加项的内容,或者验证保存的内容在 LookML 更改后是否仍能正常运行。在这些情况下,您可以使用 Gazer 在实例之间复制内容。
LookML 信息中心
在常规 LookML CI/CD 工作流期间,LookML 信息中心会在实例之间同步。不过,如果任何 UDD 与 LookML 信息中心同步,则可以使用 Gazer 通过以下命令更新这些 UDD:
gzr dashboard sync_lookml DASHBOARD_ID --host TARGET_SYSTEM_URL
用户定义的信息中心
您可以使用 Gazer 迁移用户定义的信息中心 (UDD),方法是引用信息中心的 ID 和 UDD 所在的 Looker 实例的网址。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