Using version control and deploying（バージョン管理機能の使用とデプロイ）

このページでは、プロジェクトがバージョン管理用にすでに設定されていることを前提としています。このページで説明されている選択肢の代わりに [Git の構成] ボタンが表示されている場合は、最初にプロジェクトの Git を設定する必要があります。

Looker では、変更の記録とファイルのバージョン管理のために、Git を使用します。各 LookML プロジェクトは Git リポジトリに対応しており、各デベロッパー ブランチは Git ブランチに関連付けられています。

Looker は、多くの Git プロバイダ（GitHub、GitLab、Bitbucket など）と連携するように構成できます。Looker プロジェクト用の Git の設定については、Git 接続の設定とテストのドキュメント ページをご覧ください。

Git ブランチの操作

Git の主な利点の 1 つは、Looker のデベロッパーがブランチ（ファイル リポジトリの分離されたバージョン）で作業できる点です。他のユーザーに影響を与えることなく開発とテストを行うことができます。Looker のデベロッパーは、Development Mode のときは常に Git ブランチを使用します。

Git のもう 1 つの主な特長は、他のデベロッパーとの共同作業のしやすさです。ブランチを作成し、必要に応じて変更を行うと、他のデベロッパーがそのブランチに切り替えて、ブランチを確認または変更できます。別のデベロッパーがブランチへの変更を commit した場合、Looker には [リモートの変更をプル] ボタンが表示されます。追加の変更を行う前に、commit された変更をブランチに pull する必要があります。

マスターブランチ、現在のブランチ、デベロッパーの個人用ブランチ以外のブランチを削除することもできます。

個人用のブランチ

初めて Development Mode に入ると、Looker によって個人の Git ブランチが自動的に作成されます。dev- で始まり、ユーザー名が含まれる個人用ブランチ。

個人用ブランチはユーザー固有のもので、削除できません。個人用ブランチは他のすべてのデベロッパーに対して読み取り専用になります。プロジェクトで他のデベロッパーとコラボレーションしている場合は、新しいブランチを作成することで、そのブランチに切り替えたり、変更を提供したりできます。

新しい Git ブランチを作成する

単純な修正を行っていて、他のデベロッパーとコラボレーションしていない場合は、通常、個人用ブランチが作業に適しています。個人用のブランチを使用してすばやく更新を行い、変更を commit して本番環境に push できます。

ただし、個人用ブランチに加えて、新しい Git ブランチを作成することが必要になる場合もあります。次のような場合には新しい Git ブランチが有効です。

  • 他のデベロッパーとコラボレーションしている。個人用ブランチは他のデベロッパーには読み取り専用で、他のデベロッパーとコラボレーションする場合は、他のデベロッパーがブランチに書き込めるように新しい Git ブランチを作成する必要があります。他のユーザーと共同編集している場合は、作業を再開するたびに変更を pull するようにしてください。これにより、作業を続行する前に、すべてのデベロッパーからの最新情報を確認できます。
  • 一度に複数の機能セットを扱う。大きなプロジェクトの最中に、軽微な問題を解決したり、すぐに修正したりする必要がある場合があります。この場合、表示しているブランチに変更を commit してから、別のブランチを作成するか、別のブランチに切り替えて別の機能セットで作業できます。新しいブランチで問題を修正し、そのブランチの変更を本番環境にデプロイしてから、元のブランチで作業を再開できます。

新しいブランチを作成する前に:

  • 現在のブランチでマージの競合が発生している場合は、新しいブランチを作成する前に競合を解決する必要があります。
  • 現在のブランチで commit されていない変更がある場合は、新しいブランチを作成する前に、現在のブランチで変更を commit する必要があります。
  • （本番環境ブランチではなく）既存の開発ブランチからブランチを作成する場合は、まずその開発ブランチに切り替えて、開発ブランチの最新バージョンを取得してから、リモート変更を pull して、そのブランチのローカル バージョンを同期します。

新しい Git ブランチを作成するには:

  1. Development Mode がオンになっていることを確認します。

  2. [Develop] メニューでプロジェクト ファイルに移動します。

  3. 左側のアイコン メニューで Git アイコンを選択し、[Git Actions] パネルを開きます。

  4. [View Branches] プルダウン メニューを選択します。

  5. [New Branch] を選択します。

  6. [新しいブランチ] ウィンドウで、ブランチの名前を入力します。Git ブランチ名には制限があります。命名要件については、このページのGit ブランチの命名規則をご覧ください。

  7. [Create From] プルダウン メニューを選択し、新しいブランチの出発点として使用する既存のブランチを選択します。

  8. [作成] を選択してブランチを作成します。

また、プロジェクトの設定の [ブランチの管理] タブから Git ブランチを作成することもできます。

Git ブランチの命名規則

Looker は Git で指定されたブランチ命名規則の要件を使用します。

Git ブランチ名は次のことはできません。

  • スペース文字を含める
  • ダブルピリオドを含む: ..
  • バックスラッシュを含む: \
  • シーケンスを含む: @{
  • 疑問符を含む: ?
  • 左角かっこを含む: [
  • ASCII 制御文字のいずれかを含む: ~、\^、:
  • ピリオドで始まる: .
  • 接頭辞 dev- で始まる（Looker デベロッパーの個人ブランチ用に予約されている）
  • スラッシュで終わる: /
  • 次の拡張子で終わる: .lock

さらに、ブランチ名にはアスタリスク（*）のみを使用できます。アスタリスクがパス コンポーネント全体（例: foo/* または bar/*/baz）を表している場合、ワイルドカードとして解釈されます。実際のブランチ名の一部ではありません。

別の Git ブランチに切り替える

現在のブランチでマージの競合が発生している場合は、別のブランチに切り替える前に競合を解決する必要があります。

また、現在のブランチで commit されていない変更がある場合、現在のブランチでその変更を commit するまで、既存のブランチに切り替えることはできません。

別の Git ブランチに切り替える手順は次のとおりです。

  1. 左側のアイコン メニューで Git アイコンを選択して、[Git Actions] パネルに移動します。
  2. [Git アクション] パネルで、現在の Git ブランチ名の右側にある Git ブランチのプルダウン メニューを選択します。
  3. メニューからブランチを選択するか、検索ボックスにブランチ名を入力して、切り替え先のブランチを選択します。ブランチ名の検索では大文字と小文字が区別されません。たとえば、「DEV」を検索すると、「dev」、「DEV」、「Dev」などを含む名前を持つすべてのブランチを表示できます。

Git ブランチの管理

プロジェクトの設定ページの [ブランチ管理] タブに、Looker プロジェクトのすべての Git ブランチのテーブルが表示されます。[ブランチ管理] タブを開くには、まず左側のアイコン メニューから [設定] アイコンを選択してプロジェクトの設定に移動します。次に、[ブランチ管理] タブを選択します。

[Branch Management] タブでは、次のことができます。

  1. [New Branch] ボタンを選択して新しいブランチを作成します。詳細については、このページの新しい Git ブランチの作成セクションをご覧ください。
  2. 検索バーでブランチ名を検索します。
  3. [Refresh] ボタンを選択して、テーブルを更新します。
  4. 列名を選択してテーブルを並べ替えます。

表には次の情報が含まれています。

  • 名前: Git ブランチの名前。Looker デベロッパーの個人用ブランチは、dev- で始まり、デベロッパーの姓と名が含まれます。
  • ステータス: ブランチのローカル バージョンとブランチのリモート バージョンの違い。たとえば、ステータスが 3 commits behind の場合、ブランチのローカル バージョンは、3 回の commit 分、ブランチのリモート バージョンより遅れています。Looker は常にリモート バージョンの master を使用するため、[ブランチ管理] タブには、master ブランチのローカル バージョンのステータスは表示されません。マスター ブランチは常に最新の状態であると見なすことができます。
  • Last Updated: Looker デベロッパーがブランチを commit した時間。
  • Actions: ブランチを削除するボタン、またはブランチを削除できない理由。

Git ブランチの削除

[ブランチ管理] タブから、テーブルに [削除] ボタンがあるブランチを削除できます。次のブランチは削除できません。

テーブルでは、ブランチには [Delete] ボタンはありません。テーブルの [Action] 列には、ブランチを削除できない理由が表示されます。

削除したブランチを復元することはできません。ブランチを削除すると、Looker によりブランチのローカル バージョンとリモート バージョンの両方が削除されます。

ただし、別の Looker デベロッパーによってブランチが作成された場合や、他のデベロッパーがブランチをチェックアウトした場合、それらのデベロッパーにはブランチのローカル バージョンが引き続き存在します。Looker デベロッパーがブランチのローカル バージョンに commit を実行して本番環境に push すると、ブランチのリモート バージョンが再び表示されます。これは、ブランチを復元する場合に役立ちます。それ以外の場合は、ブランチを削除すると、他のすべての Looker デベロッパーが同じブランチを削除して、他のユーザーがリモートに push して誤って再表示されないようにする必要があります。

プロジェクトから 1 つ以上の Git ブランチを削除するには、左側のアイコン メニューから [設定] アイコンを選択して、まずプロジェクトの設定に移動します。次に、[ブランチ管理] タブを選択します。[ブランチ管理] タブでは、次の 2 つの方法でブランチを削除できます。

  1. 複数のブランチを削除するには、ブランチのチェックボックスをオンにしてから、[Delete Selected Branches] を選択します。
  2. ブランチ名の横にある [Delete] を選択して、1 つのブランチを削除します。

Looker での Git コマンドの実行

Looker には、Git サービスと統合するインターフェースが組み込まれています。Looker では、LookML IDE の右上に Git ボタンが表示されます。

Git ボタンには、変更と本番環境へのデプロイにおいてどの段階にあるかに応じて異なるオプションが表示されます。通常、ボタンに表示されるオプションが、次のアクションに最適なガイドとなります。

デベロッパー ブランチが本番環境ブランチと同期している場合、Git ボタンには「Update to Date」メッセージが表示され、選択できません。

プロジェクトが Git 用に構成されたら、[Git アクション] ボタンを選択して [Git アクション] パネルを開きます。

[Git Actions] パネルで使用できるコマンドは、変更を行って本番環境にデプロイするプロセスによって異なります。

本番環境に対する変更の取得

Looker のデフォルトの Git 統合では、Looker は次の Git ワークフローに沿ってデベロッパーにプロンプトを表示します。

つまり、デフォルトの Git 統合では、すべてのデベロッパーが変更を master というブランチにマージし、master ブランチでの最新の commit が Looker の本番環境で使用されます。

高度な Git 実装では、このワークフローをカスタマイズできます。

  • デベロッパーが Looker IDE を介して変更をマージできるようにするのではなく、デベロッパーに Git 本番環境ブランチの pull リクエストを送信させることができます。詳しくは、プロジェクトのバージョン管理設定の構成のドキュメント ページをご覧ください。
  • [Git 本番環境のブランチ名] フィールドを使用して、Looker デベロッパーのブランチがマージされるターゲット ブランチとして Looker が使用する Git リポジトリからのブランチを指定できます。詳しくは、プロジェクトのバージョン管理設定の構成のドキュメント ページをご覧ください。
  • 高度なデプロイモードを使用すると、production ブランチで最新の commit を使用するのではなく、Looker の本番環境にデプロイする別の commit SHA またはタグ名を指定できます。（別のブランチから commit をデプロイする場合は、高度なデプロイモードである Webhook または API エンドポイントを使用できます）。詳しくは、高度なデプロイモードのドキュメント ページをご覧ください。

このセクションで説明されている選択肢の代わりに [Git の構成] ボタンが表示されている場合は、最初にプロジェクトの Git を設定する必要があります。

commit されていない変更の表示

LookML IDE には、Development Mode で実行中に commit されていない変更がある場合に表示されるインジケーターがあります。詳しくは、Looker IDE の概要のドキュメント ページの追加、変更、削除のマークセクションをご覧ください。

すべてのファイルの差分の概要を取得するには、[Git Actions] パネルから [View Uncommitted Changes] オプションを選択します。

Looker の [Uncommitted Changes to Project] ウィンドウには、プロジェクトのすべてのファイルで、commit されずに保存されたすべての変更の概要が表示されます。Looker は変更ごとに次の内容を表示します。

  • 置換されたファイルの名前と追加されたファイルの名前。
    • 置換されたファイルの名前（--- で表示）と追加されたファイルの名前（+++ で表示）。多くの場合、これにより、同じファイルの異なるバージョンが表示され、リビジョンが --- a/ と +++ b/ で識別されます。
    • 削除されたファイルは、null ファイル（+++ /dev/null）の置き換えとして表示されます。
    • 追加されたファイルは、null ファイル（--- /dev/null）の置き換えとして表示されます。
  • 変更が開始される行番号。

    たとえば、-101,4 +101,4 は、ファイルの 101 行目で 4 行が削除され、4 行が追加されたことを示します。20 行が削除されたファイルは -1,20 +0,0 となり、ファイルの最初の行で 20 行が削除されてゼロ行に置き換えられたことが示されます。
  • 更新されたテキスト:
    • 削除された行は赤色で表示されます。
    • 追加された行は緑色で表示されます。

1 つのファイルの差分の概要を表示するには、ファイルのメニューから [View Changes] オプションを選択します。

変更を commit する

LookML プロジェクトに変更を加えて保存すると、IDE で LookML の検証が必要になる場合があります。このシナリオでは、Git ボタンに [LookML を検証] というテキストが表示されます。

これが必要なかどうかは、プロジェクトのコード品質の設定によって異なります。Content Validator の詳細については、LookML を検証するのドキュメント ページを参照してください。

最後にローカル ブランチを更新した後に、別のデベロッパーが本番環境ブランチに変更を加えた場合、Looker は本番環境ブランチからそれらの更新を pull する必要があります。このシナリオでは、Git ボタンに [本番環境から pull] というテキストが表示されます。

プロジェクトで高度なデプロイモードが有効になっている場合、代わりに Git ボタンに [Pull from Primary Branch] というテキストが表示されます。

変更を保存し（必要に応じて、LookML の警告やエラーを修正して）、（必要に応じて）本番環境から pull すると、Git ボタンに「Commit Changes & Push」というテキストが表示されます。

必要に応じて、commit する前に commit していない変更を確認できます。

変更を commit する準備ができたら、Git ボタンを使用して、変更を現在のブランチに commit します。Looker に [Commit] ダイアログ ボックスが表示され、追加、変更、削除されたファイルが一覧表示されます。

変更内容を簡単に説明するメッセージを入力し、同期に含めないファイルの横にあるチェックボックスをオフにします。[Commit] を選択して変更を commit します。

ビルドされていないの PDT の確認

プロジェクト内の PDT に変更を加えた場合は、プロダクションにデプロイする時点ですべての PDT が作成済みであり、それらのテーブルを本番環境バージョンとして直ちに使用できるのが最善です。プロジェクト内の PDT のステータスを確認するには、[プロジェクトの状態] アイコンを選択して、[プロジェクトの状態] パネルを開き、[PDT のステータスを検証] ボタンを選択します。

LookML プロジェクトでビルドされていない PDT を確認する方法と、開発モードで派生テーブルを操作する方法については、Looker の派生テーブルのドキュメント ページをご覧ください。

データテストの実行

プロジェクトには、LookML モデルのロジックを検証するためのデータテストを定義する 1 つ以上の test パラメータが含まれる場合があります。プロジェクトでのデータテストの設定については、test パラメータのドキュメント ページをご覧ください。

プロジェクトにデータテストが含まれていて、Development Mode を使用している場合は、いくつかの方法でプロジェクトのデータテストを開始できます。

  1. プロジェクト設定がファイルを本番環境にデプロイする前にデータテストに合格する必要があるように構成されている場合、IDE はテストを定義するファイルに関係なく、変更を commit してプロジェクトに対してすべてのテストを実行した後に [テストを実行] ボタンを表示します。変更を本番環境にデプロイする前に、データテストに合格する必要があります。
  2. [プロジェクトの状態] パネルで [データテストの実行] ボタンを選択します。テストを定義するファイルに関係なく、Looker はプロジェクト内のすべてのデータテストを実行します。
  3. ファイルのメニューから [Run LookML Tests] オプションを選択します。Looker は、現在のファイルで定義されているテストのみを実行します。

データテストを実行すると、[プロジェクトの状態] パネルに進行状況と結果が表示されます。

  • テストのクエリがすべての行に対してテストのアサーションが true になると、データテストに合格します。テスト アサーションとクエリの設定の詳細については、test パラメータのドキュメント ページをご覧ください。
  • データテストに失敗すると、[プロジェクトの状態] パネルに、テストが失敗した理由、テストでモデルのロジックにエラーが検出されたかどうか、テスト自体が無効であったかどうかに関する情報が表示されます。
  • データテスト結果で、データテストの名前を選択すると、データテストの LookML に直接移動できます。また、[Explore Query] ボタンを選択して、データテストで定義されたクエリを含む Explore を開くこともできます。

本番環境にデプロイする

ブランチに変更を commit すると、Looker IDE に変更をプライマリ ブランチにマージするように求めるプロンプトが表示されます。IDE に表示されるプロンプトの種類は、プロジェクトの構成によって異なります。

  • プロジェクトが高度なデプロイモードで構成されている場合、IDE は変更をプライマリ ブランチにマージするように求めるプロンプトを表示します。commit を統合した後は、deploy 権限を持つ Looker デベロッパーが、Looker IDE の Deployment Manager を使用するか、webhook または API エンドポイントを使用することによって、commit を本番環境にデプロイできます。
  • プロジェクトが pull リクエストを使用した Git 統合用に構成されている場合は、Git プロバイダのインターフェースを使用して pull リクエストを開くよう求められます。
  • それ以外の場合は、デフォルトの Looker Git 統合で、deploy 権限があれば、Looker IDE が変更を本番環境ブランチにマージし、Looker インスタンスの本番環境バージョンにデプロイするよう求めるプロンプトを表示します。

高度なデプロイモード

Looker のデフォルトの Git 統合では、Looker デベロッパーが開発ブランチに変更を commit し、開発ブランチを本番環境ブランチにマージします。Looker 環境にデプロイすると、Looker は本番環境ブランチで最新の commit を使用します（デフォルトの Git ワークフローと、高度な Git 実装のためのその他のオプションについては、このページの本番環境への変更を取得するセクションをご覧ください）。

Looker 環境の本番環境ブランチで最新の commit を常に使用したくない場合は、deploy 権限を持つデベロッパーが高度なデプロイ モードを使用して、Looker 環境に使用する commit を正確に指定できます。これは、各環境が異なるバージョンのコードベースを指すマルチ環境のデベロッパー ワークフローに役立ちます。また、1 人以上の開発者または管理者が、本番環境にデプロイされる変更を詳細に制御できます。

高度なデプロイモードが有効になっている場合、Looker IDE には変更を本番環境にデプロイするよう求めるプロンプトがデベロッパーに表示されません。代わりに、変更を本番環境ブランチにマージするよう求めるプロンプトが表示されます。ここから変更をデプロイする方法は次のとおりです。

  • Looker IDE で Deployment Manager を使用する
  • webhook をトリガーする

  • API エンドポイント を使用する

詳しくは、高度なデプロイモードのドキュメント ページをご覧ください。

変更による影響の確認

組織に変更を適用した後、コンテンツの検証を使用して、ダッシュボードや保存済みの Look が無効になっていないことを確認します。問題がある場合は、修正できます。

一般的な問題への対応

モデルの作成中に、次のような作業が必要になることがあります。

  • 変更を破棄する

    データモデルの変更を破棄する場合もあります。まだ保存されていない場合は、単に更新するか、ページから移動して、警告プロンプトを受け入れます。変更を保存した場合は、commit されていない変更を元に戻すセクションで説明されているように、commit されていない変更を元に戻すことができます。

  • 他のデベロッパーの作業との競合のマージを処理する

    データモデルに対して複数のデベロッパーが作業している場合、通常は Git が状況に対処します。ただし、Git ではマージの競合を解決する担当者が必要になります。

フィールドの名前の変更など、一部の変更は既存のダッシュボードや Look に影響します。前述のように、組織に変更を適用した後、コンテンツの検証を使用してコンテンツを確認し、問題を修正できます。

commit されていない変更を元に戻す

個人用開発ブランチで作業を行う際に、デプロイしたくない場合は、保存した commit されていない変更を元に戻すことができます。プロジェクト内のすべてのファイルの commit されていない変更をすべて元に戻すことも、1 つのファイルの変更のみを元に戻すこともできます。

すべてのファイルの commit されていない変更を元に戻すには:

  1. [Git アクション] パネルで [元に戻す...] オプションを選択します。
  2. 復元オプションを選択します。
    • commit していない変更のみを元に戻すには、[Revert uncommitted changes] を選択します。[変更を表示] リンクをクリックして、元に戻す変更を表示することもできます。
    • commit されていない変更や commit された変更を含むすべての変更を元に戻すには、[プロダクションに戻す] を選択します。
  3. 元に戻すプロセスを完了するには、[確認] を選択します。

1 つのファイルの内容の追加または削除を元に戻すには、ファイルのメニューから [変更内容を元に戻す] オプションを選択します。

ファイル名を変更すると、基本的に、元のファイルが削除され、新しい名前で新しいファイルを作成します。これには複数のファイルが含まれるため、[ファイルを元に戻す] オプションを使用してファイル名の変更を取り消すことはできません。ファイル名の変更を元に戻すには、[Git Actions] パネルの [元に戻す...] オプションを使用します。

また、ファイルを削除すると、そのファイルは IDE のファイル ブラウザに表示されなくなります。ファイルの削除を元に戻す場合は、[Git Actions] パネルの [元に戻す...] オプションを使用します。

マージの競合の解決

通常、Git では新しい変更を LookML ファイルの本番環境バージョンと自動的に統合できます。Git で競合する変更が発生し、保持する必要がある変更を特定できない場合、結合の競合が発生します。通常は、同じ領域で最後に pull して変更を行った後に、別のデベロッパーが変更を行った場合です。コードに結合の競合がある場合、変更を commit して本番環境から pull した後に、Looker で [結合の競合] という警告が表示されます。

Looker で結合の競合という警告が表示されたら、さらに変更を行う前に結合の競合を解決することをおすすめします。結合の競合を本番環境に push すると、データ探索を妨げる可能性のある解析エラーが発生します。上級 Git ユーザーが変更を push して続行する場合は、[Don't Resolve] ボタンをクリックします。

LookML ファイル自体で、競合がある行が次のようにマークされます。

<<<<<<< HEAD
Your code
&#61;&#61;&#61;&#61;&#61;&#61;&#61;
Production code
>>>>>>> branch 'master'

Looker には、マージの競合を示す次のマージマーカーが表示されます。

  • <<<<<<< HEAD 競合行の先頭をマークします。
  • >>>>>>> branch 'master' は、競合行の末尾を示します。
  • ======= はコードの各バージョンを区切り、比較できるようにします。

上記の例で、your code は commit した変更を表し、production code は Git が変更を自動的にマージできなかったコードを表します。

マージの競合を解決するには:

  1. マージの競合が発生しているファイルを探します。Looker では、これらのファイルは赤でマークされます。また、<<<< や HEAD などのマージ マーカーでプロジェクトを検索して、プロジェクトのすべての競合を検出することもできます。[Git Actions] パネルに表示される統合の警告の [files] リンクをクリックして、影響を受けるファイルを見つけることもできます。
  2. ファイルで、マージの競合の行に移動し、保持しないテキストのバージョンと、マージ競合のマーカーをすべて削除します。

  3. ファイルを保存し、マージの競合が発生している他のファイルに対して上記の手順を繰り返します。

  4. マージの競合をすべて解決し、プロジェクトからすべてのマージマーカーを削除したら、変更を commit して本番環境にデプロイします。

これで、マージの競合が解決されて解決策が本番環境に push されたため、他のデベロッパーが本番環境から pull して、通常どおり作業を続行できるようになりました。

Git のガベージ コレクション

Git ガベージ コレクションは、不要なファイルをクリーンアップしてファイル リビジョンを圧縮し、Git リポジトリを最適化します。Git のガベージ コレクション（git gc）は、Looker インスタンスを更新または再起動すると自動的に実行されます。git gc の実行頻度を抑えるために、Looker は最後の git gc から 30 日間待機し、次の再起動時に git gc を実行します。

ごくまれに、git gc の実行中に変更のリモートへの push またはリモートへのブランチの push が試行されます。Looker でエラーが表示された場合は、1～2 分待ってから再度変更を push してみてください。