本页介绍了在安装和配置 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,请更新该 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 推送到生产环境。
使用 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.
Look 和信息中心的链接稳定性
默认情况下,我们会为数据洞见和信息中心分配递增的数字 ID,这些 ID 会在数据洞见或信息中心的网址中使用。不过,无法让这些内容在不同系统之间保持同步。因此,开发环境中特定信息中心的网址不会指向质量检查环境或生产环境中相同的信息中心。
对于 UDD,您可以选择在网址中使用 Slug 而非 ID。此标签名是一组半随机字符,而不是数字。您可以在导入过程中设置此标记,以便类似网址可指向开发环境、质量检查环境和生产环境中的同一 UDD。最佳实践是使用 Slug 而非 ID,尤其是在从“观看”或其他 UDD 中“点击进入”某个 UDD 时。
您可以通过检查 gzr dashboard cat
的输出来找到此 slug。您可以在信息中心网址中使用此标签,而无需使用数字 ID。
使用 Gazer 迁移用户内容
在开发环境、质量检查环境和生产环境之间复制外观和信息中心等内容通常很有用。您可能需要制作内容来展示新增的 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