マルチティア Looker CI/CD の使用とワークフロー

このページでは、マルチティア CI/CD ワークフローがインストールおよび構成された後に、Looker でマルチティア CI/CD ワークフローを使用する方法について説明します。

この手順では、開発、QA、本番からなる 3 層システムを使用します。ただ、同じ原則は 2 層および 4 層のシステムにも適用できます。

またこの手順では、Git プロバイダとして GitHub を使用することを前提としています。他の Git プロバイダを使用して CI/CD ワークフローを作成できますが、プロバイダに合わせてこれらの手順を変更する場合は、専門知識が必要です。

ワークフローの概要

LookML デベロッパーはまず、開発ブランチ（通常は dev-my-user-ydnv のような名前）でコードを記述し、Looker の継続的インテグレーション（または CI スイートを手動で実行）で変更をテストし、コードを commit します。最後に、pull リクエストを開き、コードを main ブランチとマージします。

pull リクエストが開かれると、デベロッパーが GitHub に誘導されます。デベロッパーは、従来の commit スタイルでわかりやすい PR タイトルを作成し、変更履歴に含められる説明にコメントを追加する必要があります。pull リクエストのトリガーが構成されている場合、Looker の継続的インテグレーションは pull リクエストを自動的に検証します。デベロッパーは Looker または GitHub で結果を表示できます。

次に、デベロッパーは GitHub でレビュー担当者を選択する必要があります。レビュー担当者は通知を受け取り、レビューを PR に追加できるようになります。レビュー担当者が変更を承認すると、PR は main ブランチと統合されます。Webhook が呼び出され、開発環境に変更が反映されます。

自動的に Release Please 自動化が実行され、2 番目の PR が開き、新しいタグ付きのリリースが作成されます。または、この目的のためにすでに PR が開いている場合は、Release Please はその PR を更新します。リリース PR にはバージョン番号が関連付けられています。また、含まれる変更のタイトルと説明を含む変更履歴も含まれています。

Release Please が生成した PR が承認されてマージされると、新しいバージョンタグが生成され、変更履歴が main ブランチとマージされます。Looker の QA インスタンスと本番環境インスタンスは、高度なデプロイモードを使用してこのバージョンを選択できます。

リリースの番号付けと commit の命名に関するベスト プラクティス

リリースとそれに関連するタグには、使用している環境に合わせて、好きな形で名前や番号を付けることができます。ただし、ここではセマンティック バージョニングを使用しています。これは、Release Please プラグインと適切に連携するため、強く推奨されます。

セマンティック バージョニングでは、バージョンがピリオドで区切られた 3 つの数値で構成されます: MAJOR.MINOR.PATCH

  • PATCH は、リリースでバグが修正されるたびに増分されます。
  • リリースで、下位互換性を維持しつつ機能が追加または調整されるたびに、MINOR が増分され、PATCH が 0 に戻ります。
  • 下位互換性がない機能が追加されると、MAJOR が増分され、MINOR と PATCH の両方が 0 に設定されます。

従来の commit とは、エンドユーザーへの影響に基づいて commit に名前を付けるシステムです。必須ではありませんが、従来の commit 命名の使用は Release Please プラグインでも役立ちます。

従来の commit の命名では、各 commit メッセージの先頭にが変更の範囲を示すインジケーターが付加されます。

  • バグの修正は、fix: set proper currency symbol on sale_amt format のように fix: で示されます。
  • 新しい機能は、feat: added explore for sales by territory のように feat: で示されます。
  • 互換性を破る変更がある機能は、feat!: で示されます（例: feat!: rewrote sales explore to use the new calendar view）。
  • ドキュメントが更新されても、LookML が変更されない場合、commit メッセージは doc: で始まります。

従来の commit が一貫して使用されている場合、次に使用されるセマンティック番号の決定は通常は簡単なものになります。commit ログが fix: と doc: の commit のみで構成されている場合は、PATCH の値を増分する必要があります。feat: commit がある場合は、MINOR を増分する必要があります。feat!: がある場合は、MAJOR を増分する必要があります。Release Release プラグインでは、CHANGELOG ファイルを生成して、リリースに自動的にタグ付けすることもできます。

高度なデプロイモードの使用

変更を行い、開発インスタンスで PR として送信すると、Release Please プラグインにより変更に v1.2.3 のようなバージョンタグが付けられます。Looker の高度なデプロイモードにより、これらのバージョンが QA インスタンスと本番環境インスタンスの Looker UI で利用できるようになります。

変更をデプロイするには、Looker IDE から Deployment Manager を選択します。

IDE 内の Looker Deployment Manager の場所。

Deployment Manager の右上にある [commit を選択] リンクをクリックします。次に、デプロイするタグに関連付けられているその他メニューを選択し、[環境にデプロイする] を選択します。

環境にデプロイするための Looker Deployment Manager UI。

デプロイに再度タグ付けする必要はないため、[Deploy without tagging] を選択して、[Deploy to Environment] ボタンを押します。

タグ付けなしでデプロイするための Looker Deployment Manager UI。

最後に、Deployment Manager を使用して本番環境に push します。

Looker の継続的インテグレーションの使用

開発ブランチの変更や pull リクエストの一部を確認するために、デベロッパーは Looker の継続的インテグレーションを使用できます。継続的インテグレーションには、次の検証ツールが用意されています。

これらのバリデーターを継続的インテグレーション スイートにグループ化し、pull リクエスト、スケジュール、手動で自動的に実行できます。

SQL Validator

継続的インテグレーション SQL バリデータは、Explore のディメンションがデータベースに対して正しく実行されることを検証します。LookML ビューで定義されたフィールドが、データベース内の有効な SQL 列または式に対応しているかどうかをテストします。

SQL バリデータの主な機能は次のとおりです。

詳細と構成オプションについては、継続的インテグレーション SQL バリデータのドキュメント ページをご覧ください。

LookML Validator

継続的インテグレーション LookML Validator は、LookML プロジェクトで、括弧の欠落や無効なフィールド参照などの構文エラーをチェックします。このバリデータは、Looker IDE の外部で LookML を記述するデベロッパーにとって特に便利です。

LookML Validator の主な機能は次のとおりです。

  • 実行を失敗させるメッセージの重大度レベルを決定する重大度しきい値（エラー、警告、情報）を設定できます。
  • 検証実行のタイムアウト期間を構成できます。

詳細と構成オプションについては、継続的インテグレーション LookML バリデータのドキュメント ページをご覧ください。

Content Validator

継続的インテグレーション コンテンツ バリデータは、LookML の変更後も Look やユーザー定義ダッシュボード（UDD）などの保存済みコンテンツが引き続き正しく機能するかどうかを確認します。

Content Validator の主な機能は次のとおりです。

詳細と構成オプションについては、継続的インテグレーションの Content Validatorのドキュメント ページをご覧ください。

Assert Validator

継続的インテグレーション アサート バリデータは、プロジェクトで定義された 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 スイートの管理と実行

継続的インテグレーション テストを管理して実行する手順は次のとおりです。

デフォルトでは、Look とダッシュボードには、Look またはダッシュボードの URL で使用される昇順の数値 ID が付与されます。ただし、システム間でこれらの同期を維持する方法はありません。したがって、開発中の特定のダッシュボードの URL が、QA や本番環境の同じダッシュボードを参照することはありません。

UDD の場合、URL の一部として ID の代わりにスラッグを使用するオプションがあります。スラッグは、数値ではなく半ランダムな文字セットです。スラッグはインポートの一部として設定でき、開発、QA、本番環境での同じ UDD を類似の URL で参照できます。ベスト プラクティスとして、ID の代わりにスラッグを使用することをおすすめします。UDD に Look や他の UDD から「クリックスルー」する場合には特に推奨されます。

スラッグは、gzr dashboard cat の出力を調べることで確認できます。スラッグは、ダッシュボード URL で数値 ID の代わりに使用できます。

Gazer を使用したユーザー コンテンツの移行

開発、QA、本番環境の間で 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

Looks

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