適用於 LUIS 的 DevOps 實務

重要

LUIS 將於 2025 年 10 月 1 日淘汰，而自 2023 年 4 月 1 日開始，您將無法建立新的 LUIS 資源。 建議移轉 LUIS 應用程式至交談語言理解，以享有產品持續支援和多語言功能的優點。

正在開發 Language Understanding (LUIS) 應用程式的軟體工程師可遵循下列指導方針，針對原始檔控制、自動化組建、測試和發行管理套用 DevOps 實務做法。

LUIS 的原始程式碼控制和分支策略

DevOps 所需的關鍵因素之一是原始檔控制。 原始檔控制系統可讓開發人員對程式碼共同作業，並追蹤變更。 使用分支可讓開發人員在不同版本的程式碼基底之間切換，以及獨立地與小組的其他成員一起工作。 當開發人員提出提取要求 (PR)，將某個分支的更新建議至另一分支或合併變更時，這些可以是自動化組建的觸發程式，用於建立並持續測試程式碼。

您可以使用本文件中所述的概念和指導方針，在追蹤原始檔控制系統中的變更時開發 LUIS 應用程式，並遵循這些軟體工程的最佳作法：

• 原始檔控制

  • LUIS 應用程式原始程式碼採用人們看得懂的格式。
  • 您可利用可重複的方式，從來源建立模型。
  • 原始程式碼可由原始程式碼儲存機制來管理。
  • 認證和祕密 (例如金鑰) 永遠不會儲存在原始程式碼中。

• 分支及合併

  • 開發人員可以從獨立的分支工作。
  • 開發人員可以同時在多個分支中工作。
  • 您可以透過重設基底或合併，將 LUIS 應用程式的變更從某個分支整合至另一個分支。
  • 開發人員可以將 PR 合併至父分支。

• 版本控制

  • 大型應用程式中的每個元件都應該獨立設定版本，讓開發人員只需查看版本號碼，就可以偵測重大變更或更新。

• 程式碼檢閱

  • PR 中變更會顯示為人類可看懂的原始程式碼，以便在接受 PR 之前先進行檢查。

原始檔控制

若要在原始程式碼管理系統中維護 LUIS 應用程式的 應用程式架構定義，請使用應用程式的 LUDown 格式 (.lu) 標記法。 .lu 格式是比 .json 格式更適合的格式，因為前者是人類可看懂的格式，可讓您更輕鬆地在 PR 中進行和檢查變更。

使用 LUDown 格式儲存 LUIS 應用程式

若要以 .lu 格式儲存 LUIS 應用程式，並將其置於原始檔控制下：

• 任一：從LUIS 入口網站匯出應用程式版本為 .lu，並將其新增至您的原始檔控制存放庫

• 或者：使用文字編輯器來建立 LUIS 應用程式的 .lu 檔案，並將其新增至您的原始檔控制存放庫

提示

如果您正在使用 LUIS 應用程式的 JSON 匯出，則可以將將轉換成 LUDown。 使用 --sort 選項可確保意圖和語句會依字母順序排序。
請注意，內建在 LUIS 入口網站中的 .LU 匯出功能已將輸出排序。

從來源組建 LUIS 應用程式

針對 LUIS 應用程式，若要從來源建立，表示要透過匯入 .lu 來源來建立新的 LUIS 應用程式版本，以訓練版本並加以發行。 您可以在 LUIS 入口網站或命令列中執行此動作：

• 使用 LUIS 入口網站從原始檔控制匯入應用程式的 .lu 版本，以及訓練和發佈應用程式。

• 在命令列或 CI/CD 工作流程中，使用 LUIS 的 Bot Framework 命令列介面，將應用程式的 .lu 版本從原始檔控制匯入 LUIS 應用程式，以及訓練和發佈應用程式。

原始檔控制下要維護的檔案

您應在原始檔控制下維護 LUIS 應用程式的下列檔案類型：

• LUIS 應用程式的 .lu 檔案

• 單元測試定義檔案 (語句和預期的結果)

• 批次測試檔案 (語句和預期的結果)，用於效能測試

未簽入認證和金鑰

請勿在您簽入存放庫檔案中包含金鑰或類似的機密值，因為未經授權的人員可能看到這些檔案。 您應該避免簽入的金鑰和其他值包括：

• LUIS 撰寫和預測金鑰
• LUIS 撰寫和預測端點
• Azure 資源金鑰
• 存取權杖，例如用於自動化驗證的 Azure 服務主體權杖

安全管理密碼的策略

安全管理密碼的策略包括：

• 如果您使用 Git 版本控制，可以將執行階段密碼儲存在本機檔案中，並藉由新增模式來比對檔案名與 .gitignore 檔案，以防止簽入檔案
• 在自動化工作流程中，您可以將密碼安全地儲存在該自動化技術所提供的參數設定中。 例如，如果您使用 GitHub 動作，就可以安全地將密碼儲存在 GitHub 密碼中。

分支和合併

Git 之類的分散式版本控制系統，讓小組成員能夠透過與他人共用的開發分支，來發佈、共用、檢查和反復查看程式碼變更。 請採用適合您小組的 Git 分支策略。

無論您採用哪一種分支策略，其主要原則皆是讓小組成員可以獨立處理功能分支內的解決方案，並與其他分支中的工作分開處理。

若要支援在分支中獨立處理 LUIS 專案：

• 主要分支有自己的 LUIS 應用程式。 此應用程式代表您專案目前的解決方案狀態，而其目前的使用中版本應該一律對應至主要分支中的 .lu 來源。 此應用程式 .lu 來源的所有更新都應經過審核和測試，以便將此應用程式部署到任何時間的組建環境，例如生產環境。 當 .lu 的更新從功能分支合併到主要分支時，您應該在 LUIS 應用程式中建立新的版本，並增加版本號碼。

• 每個功能分支都必須使用自己的 LUIS 應用程式實例。 開發人員在功能分支中使用此應用程式，而不會影響在其他分支中工作的開發人員。 此「開發分支」應用程式是一種工作複本，應該在刪除功能分支時一併刪除。

開發人員可以從獨立分支工作

開發人員可以透過下列方式，在 LUIS 應用程式上與其他分支分別處理更新：

1. 從主要分支 (取決於您的分支策略，通常是主要或開發) 建立功能分支。

2. 在 LUIS 入口網站中建立新的 LUIS 應用程式 (「開發分支應用程式」)，以專門支援功能分支中的工作。

   • 如果因為是在專案的另一個分支中完成工作之後儲存，所以解決方案 .lu 來源已經存在於您的分支中，請匯入 .lu 檔案以建立您的開發分支 LUIS 應用程式。

   • 如果您要開始使用新的專案，您的存放庫中還不會有主要 LUIS 應用程式的 .lu 來源。 您將會在完成功能分支工作時從入口網站匯出開發分支應用程式，並將其提交為 PR 的一部分，以建立 .lu 檔案。

3. 使用開發分支應用程式的作用中版本，以執行所需變更。 建議您只在適用於所有功能分支工作的單一版本開發分支應用程式中作業。 如果您在開發分支應用程式中建立多個版本，請小心追蹤哪個版本包含您想要在提出 PR 時簽入的變更。

4. 測試更新 - 請參閱測試 LUIS DevOps，以取得測試開發分支應用程式的詳細資料。

5. 從版本清單將開發分支應用程式的作用中版本作為 .lu 匯出。

6. 簽入您的更新，並邀請同儕審查您的更新。 如果您是使用 GitHub，則會引發提取要求。

7. 核准變更時，請將更新合併到主要分支中。 至此，您將會使用主要分支中更新的 .lu 來建立主要 LUIS 應用程式的新版本。 如需設定版本名稱的考慮，請參閱版本設定。

8. 刪除功能分支時，最好先刪除您為功能分支工作所建立的開發分支 LUIS 應用程式。

開發人員可以同時在多個分支中工作

如果您遵循上方開發人員可以從獨立分支作業所述的模式，則您會在每個功能分支中使用唯一的 LUIS 應用程式。 單一開發人員可以同時處理多個分支，只要這些分支切換至目前正在處理分支的正確開發分支 LUIS 應用程式即可。

建議您針對功能分支和您為功能分支工作所建立的開發分支 LUIS 應用程式使用相同名稱，以避免您不慎在錯誤的應用程式上作業。

如上所述，為了簡單起見，我們建議您在每個開發分支應用程式中使用單一版本。 如果您使用多個版本，當您在開發分支應用程式之間切換時，請務必小心啟用正確的版本。

多個開發人員可以同時在相同的分支上工作

您可以同時支援多個同時處理相同功能分支的開發人員：

• 開發人員會在正常情況下，簽出與其他開發人員一起提交的相同功能分支和推送和提取變更。

• 如果您遵循上方開發人員可以從獨立分支作業所述的模式，則此分支會使用唯一的 LUIS 應用程式支援開發。 在功能分支中開始工作的開發小組第一位成員，將會建立該「開發分支」LUIS 應用程式。

• 將小組成員新增為開發分支 LUIS 應用程式的參與者。

• 當功能分支工作完成時，請從版本清單將開發分支 LUIS 應用程式的作用中版本匯出為 .lu、將更新的 .lu 檔案儲存在存放庫中，然後簽入並 PR 變更。

使用重設基底或合併，將變更從某個分支合併到另一個分支

您小組中在其他分支工作的其他開發人員，可能會在您建立功能分支之後，對 .lu 來源進行更新並將其合併到主要分支。 您可能會想要將其變更併入您的工作版本，然後繼續在您的功能分支內進行變更。 您可以藉由重設基底或合併至主要分支進行此操作，其方式與任何其他程式碼資產相同。 由於 LUIS 應用程式的 LUDown 格式可讓人類看懂，因此支援使用標準合併工具進行合併。

如果您要在功能分支中重定基底 LUIS 應用程式，請遵循下列秘訣：

• 在重設基底或合併之前，請先從入口網站重新匯出您的應用程式，以確定應用程式 .lu 來源的本機複本具有您已使用 LUIS 入口網站套用的所有最新變更。 如此一來，您便可確定您在入口網站中已進行但尚未匯出的任何變更都不會遺失。

• 在合併期間，使用標準工具來解決任何合併衝突。

• 請不要忘記重設基底或合併後，將應用程式重新匯回入口網站，以便在您繼續套用自己的變更時，能使用已更新的應用程式。

合併 PR

在您的 PR 獲得核准之後，便可將變更合併至主要分支。 適用於 LUIS 應用程式的 LUDown 來源並無任何特殊考慮：其可由人類讀懂，因此支援使用標準合併工具進行合併。 任何合併衝突的解決方式，都與其他原始檔相同。

合併 PR 之後，建議您清除：

• 刪除存放庫中的分支

• 刪除您為功能分支工作所建立的「開發分支」LUIS 應用程式。

您應該使用與應用程式程式碼資產相同的方式，撰寫單元測試以伴隨 LUIS 應用程式更新。 您應採用持續整合工作流程來進行測試：

• PR 合併前 PR 中的更新
• PR 已核准且變更已合併至主要分支後的主要分支 LUIS 應用程式。

如需有關測試 LUIS DevOps 的詳細資訊，請參閱 LUIS 測試 DevOps。 如需如何執行工作流程的詳細資訊，請參閱 LUIS DevOps 的自動化工作流程。

程式碼檢閱

LUDown 格式的 LUIS 應用程式可由人類讀懂，並可支援 PR 中適用於檢閱的變更通訊。 單元測試檔案也會以 LUDown 格式撰寫，並可在 PR 中輕鬆檢閱。

版本控制

應用程式是由多個元件所組成，這些元件可能包含在 Azure AI Bot 服務、QnA Maker、Azure AI 語音服務等專案中執行的機器人。 若要達到鬆散結合的應用程式目標，請使用版本控制，讓應用程式的每個元件獨立設定版本，讓開發人員只需查看版本號碼，就可以偵測重大變更或更新。 如果您在自己的存放庫中維護 LUIS 應用程式，就可以更輕鬆地將其與其他元件分開。

適用於主要分支的 LUIS 應用程式應套用版本控制配置。 當您將 LUIS 應用程式的更新合併到 .lu 主要分支時，您會接著將該更新的來源匯入至主要分支的 LUIS 應用程式中的新版本。

建議您針對主要 LUIS 應用程式版本使用數值版本設定配置，例如：

major.minor[.build[.revision]]

每次更新時，版本號碼都會在最後一個位數遞增。

主要/次要版本可用來指出 LUIS 應用程式功能的變更範圍：

• 主要版本：重大變更，例如支援新的意圖或實體
• 次要版本：回溯相容的次要變更，例如重要的新訓練
• 組建：沒有任何功能變更，只是不同的組建。

一旦您決定了主要 LUIS 應用程式最新版本的版本號碼，就必須建立並測試新的應用程式版本，並將其發佈至可在不同組建環境中使用的端點，例如品質保證或生產環境。 強烈建議您在持續整合 (CI) 工作流程中自動化上述所有步驟。

請參閱：

• 自動化工作流程，以取得如何執行 CI 工作流程來測試和發行 LUIS 應用程式的詳細資料。
• 發行管理，以取得如何部署 LUIS 應用程式的詳細資訊。

版本設定「功能分支」 LUIS 應用程式

當您使用的「開發分支」LUIS 應用程式已建立為支援功能分支中的工作時，您將會在工作完成時匯出您的應用程式，且將會在 PR 中包含更新的 'lu。 在將 PR 合併到主要分支後，應該刪除您存放庫中的分支和「開發分支」LUIS 應用程式。 因為此應用程式只為支援功能分支中的工作而存在，所以沒有您需要在此應用程式中套用的特定版本設定配置。

當您 PR 中的變更合併到主要分支時，同樣也會套用版本控制，以對主要分支的所有更新獨立建立版本。

下一步

• 深入了解測試 LUIS DevOps
• 深入了解如何使用 GitHub 實作 LUIS 的 DevOps