次の方法で共有

LUIS DevOps の継続的インテグレーションと継続的デリバリーのワークフロー

  • [アーティクル]

重要

LUIS は 2025 年 10 月 1 日に廃止され、2023 年 4 月 1 日から新しい LUIS リソースを作成できなくなります。 継続的な製品サポートと多言語機能のベネフィットを得るために、LUIS アプリケーションを会話言語理解に移行することをお勧めします。

Language Understanding (LUIS) アプリを開発するソフトウェア エンジニアは、ソース管理、自動ビルド、テスト、リリース管理に DevOps プラクティスを適用できます。 この記事では、LUIS で自動ビルドを実装するための概念について説明します。

LUIS のビルド自動化ワークフロー

CI ワークフロー

ソース コード管理 (SCM) システムで、次のイベント時に実行されるように自動ビルド パイプラインを構成します。

  1. Pull request (PR) が発生したときにトリガーされる PR ワークフロー。 このワークフローでは、更新がメイン ブランチにマージされる前に PR の内容を検証します。
  2. メイン ブランチに更新がプッシュされたとき (たとえば、PR からの変更をマージしたとき) にトリガーされる CI/CD ワークフロー。 このワークフローでは、メイン ブランチに対するすべての更新の品質を保証します。

CI/CD ワークフローでは、2 つの補完的な開発プロセスを組み合わせます。

  • 継続的インテグレーション (CI) は、共有リポジトリでコードを頻繁にコミットし、それに対して自動ビルドを実行するエンジニアリング手法です。 自動テストのアプローチと継続的インテグレーションを組み合わせると、更新のたびに LUDown ソースがまだ有効であり LUIS アプリにインポートできることに加えて、ソリューションに必要な意図とエンティティがトレーニング済みアプリで認識できることを検証する一連のテストにそれが合格することを検証できます。

  • 継続的デリバリー (CD) では、より詳細なテストを実行できる環境にアプリケーションを自動的にデプロイするために、継続的インテグレーションの概念をさらに取り入れます。 CD を使用すれば、変更によって起きる予期しない問題について、できるだけ早く知ることができ、テスト カバレッジのギャップについても知ることができます。

継続的インテグレーションと継続的デリバリーの目標は、"メインはいつでもリリース可能な状態である" ことの保証です。 LUIS アプリの場合、これは、必要であればメイン ブランチの LUIS アプリから任意のバージョンを取得して運用環境にリリースできるという意味です。

LUIS の自動化ワークフローを構築するためのツール

ヒント

DevOps を実装するための完全なソリューションは、LUIS DevOps テンプレートのリポジトリで確認できます。

ビルド自動化ワークフローの作成に使用できる、さまざまなビルド自動化テクノロジがあります。 これらすべてのテクノロジで必要なのは、コマンド ライン インターフェイス (CLI) または REST 呼び出しを使用してステップをスクリプト化し、ビルド サーバーで実行できることです。

LUIS のビルド自動化ワークフローには、次のツールを使用します。

PR ワークフロー

既に説明したように、機能ブランチからメイン ブランチにマージする変更を提案するために開発者が PR を提起すると実行されるように、このワークフローを構成します。 その目的は、メイン ブランチにマージされる前に、PR での変更の品質を検証することです。

このワークフローは次のようになります。

  • PR で .lu ソースをインポートして、一時的な LUIS アプリを作成します。
  • LUIS アプリ バージョンをトレーニングし、発行します。
  • それに対してすべての単体テストを実行します。
  • すべてのテストに合格した場合はワークフローを合格とし、それ以外の場合は不合格とします。
  • 一時的なアプリをクリーンアップして削除します。

SCM でサポートされている場合、このワークフローが正常に完了しない限り PR を完了できないというブランチ保護ルールを構成します。

メイン ブランチの CI/CD ワークフロー

PR での更新がメイン ブランチにマージされた後に実行されるように、このワークフローを構成します。 その目的は、更新をテストすることにより、メイン ブランチの高い品質基準を維持することです。 更新が品質基準を満たしている場合、このワークフローにより、新しい LUIS アプリ バージョンが、より詳細なテストを実行できる環境にデプロイされます。

このワークフローは次のようになります。

  • 更新されたソース コードを使用して、プライマリ LUIS アプリ (メイン ブランチ用に保守するアプリ) で新しいバージョンをビルドします。

  • LUIS アプリ バージョンをトレーニングし、発行します。

    Note

    自動ビルド ワークフローでのテストの実行に関するページで説明しているように、テスト中の LUIS アプリ バージョンを発行して、NLU.DevOps などのツールがアクセスできるようにする必要があります。 LUIS で LUIS アプリ用にサポートされている名前付き発行スロットは staging と production の 2 つだけですが、バージョンを直接発行してバージョンによるクエリを実行することもできます。 名前付き発行スロットを使用するという制限を回避するには、自動化ワークフローで直接バージョン発行を使用します。

  • すべての単体テストを実行します。

  • 必要に応じてバッチ テストを実行して、LUIS アプリ バージョンの品質と精度を測定したり、LUIS アプリ バージョンを何らかのベースラインと比較したりします。

  • テストが正常に完了した場合:

    • リポジトリでソースにタグを付けます。
    • 継続的デリバリー (CD) ジョブを実行して、さらなるテストのための環境に LUIS アプリ バージョンをデプロイします。

継続的デリバリー (CD)

CI/CD ワークフローの CD ジョブは、ビルドと自動ユニット テストの成功時に条件付きで実行されます。 そのジョブは、さらなるテストを実行できる環境に LUIS アプリケーションを自動的にデプロイするためのものです。

いかに最適に LUIS アプリをデプロイするかに関する 1 つの推奨ソリューションは存在せず、プロジェクトに適したプロセスを実装する必要があります。 LUIS DevOps テンプレート リポジトリでは、このための簡易なソリューションとして、production 発行スロットに新しい LUIS アプリ バージョンを発行するという動作を実装しています。 簡易なセットアップでは、これで問題ありません。 ただし、開発、ステージング、UAT など、さまざまな運用環境を同時にサポートする必要がある場合、アプリごとに 2 つの名前付き発行スロットという制限は不十分さを露呈します。

アプリ バージョンをデプロイするためのその他のオプションには、以下のものがあります。

  • アプリ バージョンを直接バージョン エンドポイントに発行したままにし、下流の運用環境に直接バージョン エンドポイントを必要に応じて構成するプロセスを実装します。
  • 運用環境ごとに異なる LUIS アプリを保守します。また、LUIS アプリをトレーニングして発行するために、デプロイ先の運用環境の LUIS アプリで .lu を新しいバージョンにインポートするための自動化ステップを記述します。
  • テストした LUIS アプリ バージョンを LUIS Docker コンテナーにエクスポートし、LUIS コンテナーを Azure Container instances にデプロイします。

リリース管理

一般に、継続的デリバリーは、開発やステージングなど、運用以外の環境に対してのみ実行することを推奨します。 ほとんどのチームでは、運用環境へのデプロイに手動のレビューと承認プロセスが必要です。 運用環境へのデプロイの場合、必ず開発チームの主要担当者がサポートできるとき、またはトラフィックの少ない時間帯に実行することをお勧めします。

GitHub Actions を使用して LUIS アプリ開発に DevOps を適用する

LUIS の DevOps およびソフトウェア エンジニアリングのベスト プラクティスを実装する完全なソリューションについては、LUIS DevOps テンプレート リポジトリにアクセスしてください。 このテンプレート リポジトリを使用すると、CI/CD ワークフローとプラクティスの組み込みサポートを備えた独自のリポジトリを作成できます。これにより、独自のプロジェクトで LUIS を使用したソース管理、自動ビルド、テスト、リリース管理が可能になります。

LUIS DevOps テンプレート リポジトリでは、次を行う方法を説明しています。

次のステップ