Looker リリースの概要

Looker の迅速なリリース サイクルにより、チームはユーザーのフィードバックを迅速に取り入れ、優先度の高い項目にタイムリーに対応できます。このガイドでは、Google の標準的なリリースと更新プロセス、そしてニーズに合ったベスト プラクティスとバリエーションについて説明します。

開発とリリースのサイクル

新しいマイナー バージョンの Looker はおよそ 2 週間でデプロイされます。12 月は新しいリリースやデプロイは行われません。

次の更新を待たずに、修正のための小規模な更新パッチがリリースされることもあります。プロダクトやセキュリティに関する重大な問題に対する修正はほぼ常時行われています。パッチリリースには新機能が含まれないのが理想的です。パッチ更新の適用は、標準リリース中のアップグレードと同じプロセスで行われます。

リリース番号

Google のリリース番号付けスキームでは 3 つの番号シーケンス(XYZ)を使用します。ここで、X はリリース年の下 2 桁、Y は月次バージョン(1 月の 0 から始まり、それ以降の各月で偶数を使用)、Z はパッチ リリース バージョンです。たとえば、2023 年 3 月の Looker リリースの最初のパッチは Looker 23.4.1 になります。

リリースノート

すべてのユーザーは、Looker の [アカウント設定] セクションでリリースノートにオプトインできます。また、Looker インスタンス([管理者] セクションの [全般設定] にあります)で技術担当者として登録されている人には、リリースノート通知が届きます。

リリースノートで、新機能や問題の修正についての最新情報を確認できます。最新のリリースのリリースノートと変更履歴へのリンクについては、Looker のリリースページをご覧ください。Looker のリリースページには、過去のリリースノートへのリンクもあります。

環境のステージングとテスト

Looker ではリリース前に効果的なテストを実施できるよう最大の努力をしていますが、特定の設定や使用によって Looker の新機能が予期しない影響を受ける可能性があります。メインの本番環境インスタンスに新しいリリースを push する前に、Looker ホスト型インスタンスとセルフホスト型インスタンスの両方で、ステージング環境を利用して LookML をテストし、サードパーティとインターフェースできます。また、インスタンスがセルフホスト型の場合は、技術的な設定もテストできます。

ステージング環境の利用に関心がある場合は、Looker サポートまたは Looker のアカウント担当者を通じて Looker サポートにお問い合わせください。

プロセスの更新

更新デプロイ プロセスの所有権は、Looker インスタンスのホスト方法によって異なります。以下に詳細を示しますが、概要としては、インスタンスが Looker ホスト型の場合は、Looker が更新プロセスを管理します。インスタンスがセルフホスト型の場合は、更新の実行手順が示されます。

Looker ホスト型インスタンスに関する更新情報

インスタンスが Looker ホスト型の場合(つまり、インスタンスのインフラストラクチャが Looker によって管理されている場合)、Looker のリリースチームと運用チームは指定されたメンテナンスの時間枠中に更新を適用します。Looker からのメール配信に登録されている場合は、メンテナンスの時間枠の日時を記載した新しいリリースのお知らせをお送りします。メンテナンスの中断を最小限に抑えるために、更新にはメンテナンスの時間枠を使用し、通常 10 分程度で終了します。

Looker では、アップデートが順次適用されます。更新は、インスタンス設定の特性、組織内での Looker の使用方法、各会社がサイクルの早い時期または後半のどちらにリリースを希望されるかに基づいて適用されます。ソフトウェア リリースの場合と同様に、新しいマイナー バージョンの最初のパッチ バージョンにはプロダクトの問題が含まれる可能性が高くなります。ただし、Looker ホスト型インスタンスの場合は、パッチが利用可能になり次第、すぐに適用できます。

新しいリリース バージョンをスキップする場合

Google Cloud コンソールから Looker サポートにお問い合わせいただくか、Google の専任アカウント チームにお問い合わせください。お客様のビジネスニーズを確実に満たせるようサポートいたします。

セルフホスト型 Looker インスタンスに関する最新情報

セルフホスト型 Looker インスタンスでは、リリース バージョンの更新を管理する責任はお客様にあります。サポート対象外のリリースやサポートが終了したリリースを実行することのないように、サポートされている最新のリリースを使用することが極めて重要です。Looker のセルフホスト型インスタンスは、リリースのロールアウト サイクルの終了前に更新通知を受け取ります。これにより、重大な問題に事前に対処できます。

新しいリリースをインストールする準備が整うと、組織の技術担当者として登録されている Looker ユーザーに、最新の更新ファイル(JAR 形式)、リリースノート、手順へのリンクが記載されたメールが送信されます。

以前のバージョンにロールバックしないことを強くおすすめします。その代わりに、アップデートの前に必ずシステムのバックアップを取ってください。これにより、インスタンスを以前のバージョンに復元できます。バックアップなしで以前のバージョンに復元すると、元に戻せないコンテンツ損失とインスタンスへの損害が発生する可能性があります。

早期アクセス

ロールアウト プロセスの速い段階で更新情報を受け取ることが会社のビジネスニーズに合致することから、新しいリリースへの早期アクセスをご希望の場合は、こちらからご登録いただくか、サポート リクエストを送信してください。

拡張サポート リリース プログラム

短いリリース サイクルに関連するプロダクトの迅速な改善は、多くの組織に賛同を頂いていますが、Looker は、このペースに伴うトレードオフと、特定のビジネス ユースケースにはより長いサイクルが適している理由について理解しています。

これらのニーズを満たすために、2 回おきに、マイナーリリースを拡張サポート リリース(ESR)バージョンとして指定します。Google では、各リリースで製品の安定性を最大限に高めるよう最善を尽くしますが、ESR として指定されたリリース バージョンでは、十分な時間をかけてテストと問題の修正が行われます。

また、ESR については、開発とプロダクト サポートのための時間をより長く確保し、重大度 1 と重大度 2 レベルの問題には可能な限りパッチを適用します(該当する場合)。

新しい ESR リリースの検証

ESR 間のプロダクトの変化が大きいため、各 ESR には 1 か月のステージング期間があります。このプログラムの一環として、最初にステージング サーバーで新しい ESR バージョンの更新を実行する必要があります。これにより、本番環境サーバーを新しい ESR バージョンに移行する前に、コンテンツ、ワークフロー、新機能をテストできます。

ESR プログラムにオプトインする

ESR プログラムが貴社のビジネスニーズにより適していると思われる場合は、カスタマー サクセス チームに問い合わせて、このオプションについてご相談ください。

ご不明な点がある場合は、

ご不明な点がある場合は、Looker のコミュニティ フォーラムをご利用ください。Looker、ビジネス インテリジェンス、データ全般、他の優れた Looker(お客様)や Looker アナリストを含めて(ただし、これらに限定されません)、あらゆる種類のディスカッションが歓迎されています。