Looker 문서를 보고 있습니다. Looker Studio 문서는 https://support.google.com/looker-studio를 참조하세요.

Looker CI/CD 사용 및 워크플로

이 페이지에서는 이러한 워크플로가 설치 및 구성된 후 Looker에서 CI/CD 워크플로를 사용하는 방법을 설명합니다.

이 안내에서는 개발, 품질 보증, 프로덕션으로 구성된 3계층 시스템을 사용합니다. 하지만 2계층 또는 4계층 시스템에 동일한 원칙을 적용할 수 있습니다.

이 안내에서는 GitHub를 Git 제공업체로 사용한다고 가정합니다. 다른 Git 제공업체를 사용하여 CI/CD 워크플로를 만들 수 있습니다. 하지만 제공업체를 위해 이 안내를 수정할 수 있는 전문성을 보유하고 있어야 합니다.

워크플로 개요

LookML 개발자는 일반적으로 개발 브랜치에서 dev-my-user-ydnv와 같은 이름의 코드를 작성하고 Spectacles로 변경사항을 테스트한 다음 코드를 커밋합니다. 마지막으로 코드를 main 브랜치와 병합하는 pull 요청을 엽니다.

pull 요청이 열리면 개발자가 GitHub로 이동합니다. 개발자는 기존 커밋 스타일을 사용하여 의미 있는 PR 제목을 작성하고 변경 로그에 포함될 주석을 설명에 추가해야 합니다. Spectacles 테스트 결과는 PR에 주석으로 추가해야 합니다.

다음으로 개발자는 GitHub에서 검토자를 선택해야 합니다. 검토자는 알림을 받게 되며 검토한 내용을 PR에 추가할 수 있습니다. 검토자가 변경사항을 승인하면 PR이 main 브랜치와 병합됩니다. 웹훅이 호출되고 이제 개발 환경에 변경사항이 표시됩니다.

자동으로 Release Please 자동화가 실행되고 두 번째 PR을 열어 태그가 지정된 새 출시 버전을 만듭니다. 또는 이 목적으로 열려 있는 PR이 이미 있는 경우 Release Please가 해당 PR을 업데이트합니다. 출시 PR에는 연관된 버전 번호뿐 아니라 포함된 변경사항의 제목 및 설명이 포함된 변경 로그가 있습니다.

Release Please가 생성한 PR이 승인되고 병합되면 새 버전 태그가 생성되고 변경 로그가 main 브랜치와 병합됩니다. Looker의 품질 보증 및 프로덕션 인스턴스가 고급 배포 모드를 사용하여 이 버전을 선택할 수 있습니다.

출시 버전 번호 지정 및 커밋 이름 지정 권장사항

출시 버전 및 관련 태그는 사용자 환경에 적합한 방식으로 이름과 번호를 지정할 수 있습니다. 하지만 여기서는 시맨틱 버전 관리가 사용되는데 이는 Release Allow 플러그인과 잘 작동하므로 사용하는 것이 좋습니다.

시맨틱 버전 관리에서 버전은 마침표로 구분된 세 개의 숫자로 구성됩니다(MAJOR.MINOR.PATCH).

출시 버전에서 버그를 수정할 때마다 PATCH가 증가합니다.
출시 버전에서 이전 버전과 호환되는 기능을 추가하거나 개선할 때마다 MINOR가 증가하고 PATCH가 0으로 다시 설정됩니다.
이전 버전과 호환되지 않는 기능이 추가되면 MAJOR가 증가하고 MINOR 및 PATCH 모두 0으로 설정됩니다.

기존 커밋은 최종 사용자에게 미치는 영향에 따라 커밋의 이름을 지정하는 시스템입니다. 필수는 아니지만 기존 커밋 이름 지정 시스템을 사용하는 것이 Release Please 플러그인에도 유용합니다.

기존 커밋 이름 지정 시스템에서는 각 커밋 메시지 앞에 변경 범위를 나타내는 표시기가 추가됩니다.

버그 수정이 fix: set proper currency symbol on sale_amt format와 같은 fix:로 표시됩니다.
새 특성이 feat: added explore for sales by territory와 같이 feat:로 표시됩니다.
브레이킹 체인지가 있는 특성이 feat!: rewrote sales explore to use the new calendar view와 같이 feat!:로 표시됩니다.
문서가 업데이트되었지만 LookML이 변경되지 않으면 커밋 메시지가 doc:로 시작합니다.

기존 커밋을 일관되게 사용하는 경우 다음에 사용할 시맨틱 번호를 결정하는 것은 일반적으로 간단합니다. 커밋 로그가 fix: 및 doc: 커밋으로만 구성된 경우 PATCH를 증가시켜야 합니다. feat: 커밋이 있는 경우 MINOR를 증가시켜야 합니다. feat!:가 있는 경우 MAJOR를 증가시켜야 합니다. Release Please 플러그인은 CHANGELOG 파일을 생성하고 출시 버전에 자동으로 태그를 지정할 수도 있습니다.

고급 배포 모드 사용

개발 인스턴스에서 변경사항이 적용되고 PR로 제출되면 Release Please 플러그인이 v1.2.3과 같은 버전 태그로 변경사항에 태그를 지정합니다. 그러면 Looker의 고급 배포 모드에서 해당 버전을 품질 보증 및 프로덕션 인스턴스에 대해 Looker UI에서 사용할 수 있도록 만듭니다.

변경사항을 배포하려면 Looker IDE에서 Deployment Manager를 선택합니다.

IDE에서의 Looker Deployment Manager 위치

Deployment Manager의 오른쪽 상단에 있는 커밋 선택 링크를 클릭합니다. 그런 다음 배포할 태그와 연결된 점 3개로 된 메뉴를 선택하고 환경에 배포를 선택합니다.

환경에 배포하기 위한 Looker Deployment Manager UI

배포에 다시 태그를 지정할 필요가 없으므로 태그 없이 배포를 선택하고 환경에 배포 버튼을 누릅니다.

태그 없이 배포하기 위한 Looker Deployment Manager UI

마지막으로 Deployment Manager를 사용하여 프로덕션으로 푸시합니다.

Spectacles 사용

각 개발자는 개발 브랜치에 있는 동안 Spectacles를 사용하여 변경사항을 확인할 수 있습니다. Spectacles는 4가지 검사기를 제공합니다.

SQL
LookML
콘텐츠
Assert

개발자가 pull 요청을 제출하면 이러한 테스트를 실행하고 그 결과를 PR의 주석에 복사하는 것이 좋습니다.

SQL 검사기

SQL 검사기는 각 Explore를 테스트하여 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 변경사항이 유효하고 구문 오류가 없는지 확인합니다. 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)와 같은 저장된 콘텐츠가 변경사항이 적용된 후에도 계속 작동하는지 테스트합니다. 작업을 더 빠르게 실행하고 관리 가능한 결과를 제공하기 위해 지정한 Explore를 기반으로 하는 콘텐츠에 대해서만 검사가 수행됩니다. 콘텐츠 검사기는 다음과 같이 호출됩니다.

$ 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 및 대시보드에는 Look 또는 대시보드의 URL에 사용되는 오름차순 숫자 ID가 제공됩니다. 하지만 시스템 간에 동기화 상태로 유지할 수 있는 방법은 없습니다. 따라서 개발 중인 특정 대시보드의 URL은 품질 보증 또는 프로덕션의 동일한 대시보드를 가리키지 않습니다.

UDD의 경우 URL의 일부로 ID 대신 슬러그를 사용하는 옵션이 있습니다. 슬러그는 숫자가 아닌 거의 무작위 문자 집합입니다. 슬러그는 가져오기의 일부로 설정할 수 있으며 유사한 URL이 개발, 품질 보증, 프로덕션에서 동일한 UDD를 가리킬 수 있습니다. 특히 Look 또는 다른 UDD에서 UDD를 클릭하여 연결할 때는 ID 대신 슬러그를 사용하는 것이 좋습니다.

슬러그는 gzr dashboard cat의 출력을 검사하여 찾을 수 있습니다. 슬러그는 대시보드 URL에서 숫자 ID 대신 사용할 수 있습니다.

Gazer로 사용자 콘텐츠 마이그레이션

Look 및 대시보드와 같은 콘텐츠를 개발, 품질 보증, 프로덕션 간에 복사하는 것이 유용한 경우가 많습니다. 새로운 LookML 추가 항목을 보여주는 콘텐츠를 생성하거나 LookML 변경사항이 적용된 후에도 저장된 콘텐츠가 올바르게 작동하는지 확인하는 것이 좋습니다. 이러한 상황에서는 Gazer를 사용하여 인스턴스 간에 콘텐츠를 복사할 수 있습니다.

LookML 대시보드

LookML 대시보드는 일반 LookML CI/CD 워크플로 중에 인스턴스 간에 동기화됩니다. 그러나 UDD가 LookML 대시보드와 동기화된 경우 다음 명령어를 사용하여 Gazer로 업데이트할 수 있습니다.

gzr dashboard sync_lookml DASHBOARD_ID --host TARGET_SYSTEM_URL

사용자 정의 대시보드

사용자 정의 대시보드(UDD)는 대시보드 ID와 UDD가 있는 Looker 인스턴스의 URL을 참조하여 Gazer로 마이그레이션할 수 있습니다. 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