Metodyki DevOps dla usługi LUIS

Ważne

Usługa LUIS zostanie wycofana 1 października 2025 r. i od 1 kwietnia 2023 r. nie będzie można utworzyć nowych zasobów usługi LUIS. Zalecamy migrację aplikacji LUIS do interpretacji języka konwersacyjnego, aby korzystać z ciągłej pomocy technicznej i wielojęzycznych możliwości produktów.

Inżynierowie oprogramowania, którzy opracowują aplikację Usługi Language Understanding (LUIS), mogą stosować rozwiązania DevOps dotyczące kontroli źródła, zautomatyzowanych kompilacji, testowania i zarządzania wydaniami , postępując zgodnie z tymi wytycznymi.

Strategie kontroli źródła i stosowania gałęzi dla usługi LUIS

Jednym z kluczowych czynników, od których zależy sukces metodyki DevOps, jest kontrola źródła. System kontroli źródła umożliwia deweloperom współpracę nad kodem i śledzenie zmian. Korzystanie z gałęzi umożliwia deweloperom przełączanie się między różnymi wersjami bazy kodu i niezależnie od innych członków zespołu. Gdy deweloperzy zgłaszają żądanie ściągnięcia w celu zaproponowania aktualizacji z jednej gałęzi do innej lub scalania zmian, mogą to być wyzwalacze dla automatycznych kompilacji w celu kompilowania i ciągłego testowania kodu.

Korzystając z pojęć i wskazówek opisanych w tym dokumencie, możesz opracować aplikację usługi LUIS podczas śledzenia zmian w systemie kontroli źródła i postępować zgodnie z następującymi najlepszymi rozwiązaniami w zakresie inżynierii oprogramowania:

• Kontrola źródła

  • Kod źródłowy aplikacji LUIS jest w formacie czytelnym dla człowieka.
  • Model można skompilować ze źródła w powtarzalny sposób.
  • Kod źródłowy może być zarządzany przez repozytorium kodu źródłowego.
  • Poświadczenia i wpisy tajne, takie jak klucze, nigdy nie są przechowywane w kodzie źródłowym.

• Rozgałęzianie i scalanie

  • Deweloperzy mogą pracować z niezależnych gałęzi.
  • Deweloperzy mogą pracować w wielu gałęziach jednocześnie.
  • Istnieje możliwość zintegrowania zmian w aplikacji usługi LUIS z jednej gałęzi z innej za pomocą bazy danych lub scalania.
  • Deweloperzy mogą scalić żądanie ściągnięcia z gałęzią nadrzędną.

• Przechowywanie wersji

  • Każdy składnik w dużej aplikacji powinien być niezależnie wersjonowany, dzięki czemu deweloperzy mogą wykrywać zmiany powodujące niezgodność lub aktualizacje, przeglądając numer wersji.

• Przeglądy kodu

  • Zmiany w żądaniu ściągnięcia są prezentowane jako czytelny dla człowieka kod źródłowy, który można przejrzeć przed zaakceptowaniem żądania ściągnięcia.

Kontrola źródła

Aby zachować definicję schematu aplikacji usługi LUIS w systemie zarządzania kodem źródłowym, użyj formatu LUDown (.lu) reprezentacji aplikacji. .lu format jest preferowany do formatowania .json , ponieważ jest czytelny dla człowieka, co ułatwia wprowadzanie i przeglądanie zmian w żądaniach ściągnięcia.

Zapisywanie aplikacji LUIS przy użyciu formatu LUDown

Aby zapisać aplikację usługi LUIS w .lu formacie i umieścić ją pod kontrolą źródła:

• ALBO: Wyeksportuj wersję aplikacji jako .lu z portalu usługi LUIS i dodaj ją do repozytorium kontroli źródła

• LUB: Użyj edytora tekstów, aby utworzyć .lu plik dla aplikacji usługi LUIS i dodać go do repozytorium kontroli źródła

Napiwek

Jeśli pracujesz z eksportem JSON aplikacji usługi LUIS, możesz przekonwertować ją na luDown. --sort Użyj opcji , aby upewnić się, że intencje i wypowiedzi są sortowane alfabetycznie.
Zwróć uwagę, że element . Funkcja eksportowania lu wbudowana w portal usługi LUIS już sortuje dane wyjściowe.

Kompilowanie aplikacji LUIS ze źródła

Aby utworzyć aplikację usługi LUIS na podstawie źródła , utworzyć nową wersję aplikacji luis, importując .lu źródło , w celu wytrenowania wersji i opublikowania jej. Można to zrobić w portalu usługi LUIS lub w wierszu polecenia:

• Użyj portalu usługi LUIS, aby zaimportować .lu wersję aplikacji z kontroli źródła i wytrenować i opublikować aplikację.

• Użyj interfejsu wiersza polecenia platformy Bot Framework dla usługi LUIS w wierszu polecenia lub w przepływie pracy ciągłej integracji/ciągłego wdrażania, aby zaimportować .lu wersję aplikacji z kontroli źródła do aplikacji usługi LUIS i wytrenować i opublikować aplikację.

Pliki do utrzymania pod kontrolą źródła

Następujące typy plików dla aplikacji USŁUGI LUIS powinny być utrzymywane pod kontrolą źródła:

• .lu plik dla aplikacji usługi LUIS

• Pliki definicji testu jednostkowego (wypowiedzi i oczekiwane wyniki)

• Pliki testów wsadowych (wypowiedzi i oczekiwane wyniki) używane do testowania wydajnościowego

Poświadczenia i klucze nie są zaewidencjonowane

Nie dołączaj kluczy lub podobnych wartości poufnych do plików zaewidencjonowanych w repozytorium, gdzie mogą być widoczne dla nieautoryzowanego personelu. Klucze i inne wartości, które należy uniemożliwić zaewidencjonowaniu, obejmują:

• Klucze tworzenia i przewidywania usługi LUIS
• Punkty końcowe tworzenia i przewidywania usługi LUIS
• Klucze zasobów platformy Azure
• Tokeny dostępu, takie jak token dla jednostki usługi platformy Azure używanej do uwierzytelniania automatyzacji

Strategie bezpiecznego zarządzania wpisami tajnymi

Strategie bezpiecznego zarządzania wpisami tajnymi obejmują:

• Jeśli używasz kontroli wersji usługi Git, możesz przechowywać wpisy tajne środowiska uruchomieniowego w pliku lokalnym i zapobiegać ewidencjonowaniu pliku przez dodanie wzorca w celu dopasowania nazwy pliku do pliku gitignore
• W przepływie pracy automatyzacji można bezpiecznie przechowywać wpisy tajne w konfiguracji parametrów oferowanych przez technologię automatyzacji. Jeśli na przykład używasz funkcji GitHub Actions, możesz bezpiecznie przechowywać wpisy tajne w wpisach tajnych usługi GitHub.

Rozgałęzianie i scalanie

Rozproszone systemy kontroli wersji, takie jak Git, zapewniają elastyczność w sposobie publikowania, udostępniania, przeglądu i iterowania zmian kodu przez gałęzie programistyczne udostępniane innym osobom. Zastosuj strategię rozgałęziania git odpowiednią dla twojego zespołu.

Niezależnie od wdrażanej strategii rozgałęziania kluczową zasadą jest to, że członkowie zespołu mogą pracować nad rozwiązaniem w gałęzi funkcji niezależnie od pracy wykonywanej w innych gałęziach.

Aby obsługiwać niezależną pracę w gałęziach przy użyciu projektu usługi LUIS:

• Gałąź główna ma własną aplikację USŁUGI LUIS. Ta aplikacja reprezentuje bieżący stan rozwiązania dla projektu, a jego bieżąca aktywna wersja powinna zawsze być mapowania na .lu źródło, które znajduje się w gałęzi głównej. Wszystkie aktualizacje .lu źródła tej aplikacji powinny być przeglądane i testowane, aby ta aplikacja mogła zostać wdrożona w środowiskach kompilacji, takich jak Produkcja w dowolnym momencie. Po scaleniu aktualizacji z .lu gałęzią główną z gałęzi funkcji należy utworzyć nową wersję w aplikacji usługi LUIS i określić numer wersji.

• Każda gałąź funkcji musi używać własnego wystąpienia aplikacji usługi LUIS. Deweloperzy pracują z tą aplikacją w gałęzi funkcji bez ryzyka wpływu na deweloperów pracujących w innych gałęziach. Ta aplikacja "dev branch" to działająca kopia, która powinna zostać usunięta po usunięciu gałęzi funkcji.

Deweloperzy mogą pracować z niezależnych gałęzi

Deweloperzy mogą pracować nad aktualizacjami aplikacji LUIS niezależnie od innych gałęzi, wykonując następujące czynności:

1. Tworzenie gałęzi funkcji z gałęzi głównej (w zależności od strategii gałęzi, zwykle głównej lub programowej).

2. Utwórz nową aplikację usługi LUIS w portalu usługi LUIS (aplikację "dev branch") wyłącznie w celu obsługi pracy w gałęzi funkcji.

   • .lu Jeśli źródło rozwiązania już istnieje w gałęzi, ponieważ zostało zapisane po zakończeniu pracy w innej gałęzi wcześniej w projekcie, utwórz aplikację usługi LUIS w gałęzi dewelopera, importując .lu plik.

   • Jeśli rozpoczynasz pracę nad nowym projektem, nie będziesz jeszcze mieć .lu źródła głównej aplikacji LUIS w repozytorium. Plik zostanie utworzony .lu przez wyeksportowanie aplikacji dev branch z portalu po zakończeniu pracy gałęzi funkcji i przesłaniu go w ramach żądania ściągnięcia.

3. Pracuj nad aktywną wersją aplikacji dev branch, aby zaimplementować wymagane zmiany. Zalecamy, aby pracować tylko w jednej wersji aplikacji usługi Dev Branch dla całej pracy gałęzi funkcji. Jeśli tworzysz więcej niż jedną wersję w aplikacji usługi Dev Branch, należy zachować ostrożność, aby śledzić, która wersja zawiera zmiany, które chcesz zaewidencjonować podczas zgłaszania żądania ściągnięcia.

4. Przetestuj aktualizacje — zobacz Testowanie usługi LUIS DevOps , aby uzyskać szczegółowe informacje na temat testowania aplikacji dev branch.

5. Wyeksportuj aktywną wersję aplikacji usługi Dev Branch jako .lu z listy wersji.

6. Zaewidencjonuj aktualizacje i zaproś równorzędny przegląd aktualizacji. Jeśli używasz usługi GitHub, zgłosisz żądanie ściągnięcia.

7. Po zatwierdzeniu zmian scal aktualizacje z gałęzią główną. Na tym etapie utworzysz nową wersję głównej aplikacji LUIS przy użyciu zaktualizowanej .lu w sekcji głównej. Zobacz Przechowywanie wersji , aby zapoznać się z zagadnieniami dotyczącymi ustawiania nazwy wersji.

8. Po usunięciu gałęzi funkcji dobrym pomysłem jest usunięcie aplikacji usługi LUIS utworzonej na potrzeby pracy gałęzi funkcji.

Deweloperzy mogą pracować w wielu gałęziach jednocześnie

Jeśli zgodnie ze wzorcem opisanym powyżej w temacie Deweloperzy mogą pracować z niezależnych gałęzi, użyjesz unikatowej aplikacji luis w każdej gałęzi funkcji. Jeden deweloper może pracować nad wieloma gałęziami jednocześnie, o ile przełączają się do właściwej aplikacji usługi LUIS dla gałęzi deweloperów, nad którą obecnie pracują.

Zalecamy użycie tej samej nazwy zarówno dla gałęzi funkcji, jak i aplikacji usługi LUIS dla gałęzi deweloperów utworzonej dla gałęzi funkcji, aby zmniejszyć prawdopodobieństwo przypadkowej pracy nad niewłaściwą aplikacją.

Jak wspomniano powyżej, zalecamy, aby dla uproszczenia pracować w jednej wersji w każdej aplikacji gałęzi deweloperów. Jeśli używasz wielu wersji, należy aktywować poprawną wersję podczas przełączania się między aplikacjami usługi Dev Branch.

Wielu deweloperów może jednocześnie pracować nad tą samą gałęzią

Możesz jednocześnie obsługiwać wielu deweloperów pracujących nad tą samą gałęzią funkcji:

• Deweloperzy sprawdzają tę samą gałąź funkcji i wypychają i ściągają zmiany przesłane przez siebie i innych deweloperów, podczas gdy praca przebiega normalnie.

• Jeśli zgodnie ze wzorcem opisanym powyżej w temacie Deweloperzy mogą pracować z niezależnych gałęzi, ta gałąź będzie używać unikatowej aplikacji usługi LUIS do obsługi programowania. Ta aplikacja usługi LUIS "dev branch" zostanie utworzona przez pierwszego członka zespołu deweloperskiego, który rozpocznie pracę w gałęzi funkcji.

• Dodaj członków zespołu jako współautorów do aplikacji usługi LUIS w gałęzi deweloperów.

• Po zakończeniu pracy gałęzi funkcji wyeksportuj aktywną wersję aplikacji USŁUGI LUIS gałęzi dewelopera, korzystając .lu z listy wersji, zapisz zaktualizowany .lu plik w repozytorium i zaewidencjonuj zmiany i ściągnij je.

Dołączanie zmian z jednej gałęzi do innej z rebase lub scalania

Niektórzy inni deweloperzy w zespole pracujący w innej gałęzi mogli zaktualizować .lu źródło i scalić je z gałęzią główną po utworzeniu gałęzi funkcji. Zanim przejdziesz do gałęzi funkcji, możesz uwzględnić ich zmiany w wersji roboczej. Można to zrobić, zmieniając bazę danych lub scalając w taki sam sposób, jak każdy inny zasób kodu. Ponieważ aplikacja LUIS w formacie LUDown jest czytelna dla człowieka, obsługuje scalanie przy użyciu standardowych narzędzi scalania.

Postępuj zgodnie z poniższymi wskazówkami, jeśli używasz aplikacji LUIS w gałęzi funkcji:

• Przed ponownym utworzeniem bazy lub scalenia upewnij się, że lokalna kopia .lu źródła aplikacji zawiera wszystkie najnowsze zmiany, które zostały zastosowane przy użyciu portalu usługi LUIS, przez ponowne wyeksportowanie aplikacji z portalu. Dzięki temu możesz upewnić się, że wszystkie zmiany wprowadzone w portalu i nie zostały jeszcze wyeksportowane, nie zostaną utracone.

• Podczas scalania użyj standardowych narzędzi, aby rozwiązać wszelkie konflikty scalania.

• Nie zapomnij po zakończeniu ponownego tworzenia bazy danych lub scalania, aby ponownie zaimportować aplikację z powrotem do portalu, aby kontynuować pracę ze zaktualizowaną aplikacją podczas stosowania własnych zmian.

Scal żądania ściągnięcia

Po zatwierdzeniu żądania ściągnięcia można scalić zmiany z gałęzią główną. Żadne specjalne zagadnienia nie dotyczą źródła LUDown dla aplikacji USŁUGI LUIS: jest czytelne dla człowieka i obsługuje scalanie przy użyciu standardowych narzędzi scalania. Wszelkie konflikty scalania mogą być rozwiązywane w taki sam sposób, jak w przypadku innych plików źródłowych.

Po scaleniu żądania ściągnięcia zaleca się czyszczenie:

• Usuwanie gałęzi w repozytorium

• Usuń aplikację usługi LUIS "dev branch" utworzoną na potrzeby pracy gałęzi funkcji.

W taki sam sposób, jak w przypadku zasobów kodu aplikacji, należy napisać testy jednostkowe, aby towarzyszyć aktualizacjom aplikacji usługi LUIS. W celu przetestowania należy stosować przepływy pracy ciągłej integracji:

• Aktualizacje w żądaniu ściągnięcia przed scaleniem żądania ściągnięcia
• Aplikacja usługi LUIS gałęzi głównej po zatwierdzeniu żądania ściągnięcia i zmiany zostały scalone z gałęzią główną.

Aby uzyskać więcej informacji na temat testowania usługi LUIS DevOps, zobacz Testowanie metodyki DevOps dla usługi LUIS. Aby uzyskać więcej informacji na temat implementowania przepływów pracy, zobacz Automation workflows for LUIS DevOps (Przepływy pracy usługi Automation dla metodyki DevOps usługi LUIS).

Przeglądy kodu

Aplikacja LUIS w formacie LUDown jest czytelna dla człowieka, która obsługuje komunikację zmian w żądaniu ściągnięcia odpowiedniego do przeglądu. Pliki testów jednostkowych są również zapisywane w formacie LUDown, a także można je łatwo przeglądać w żądaniu ściągnięcia.

Wersje

Aplikacja składa się z wielu składników, które mogą obejmować takie elementy jak bot działający w usłudze Azure AI Bot Service, QnA Maker, usługa Azure AI Speech i inne. Aby osiągnąć cel luźno powiązanych aplikacji, użyj kontroli wersji, aby każdy składnik aplikacji był wersjonowany niezależnie, umożliwiając deweloperom wykrywanie zmian powodujących niezgodność lub aktualizacji tylko przez sprawdzenie numeru wersji. Łatwiej jest używać wersji aplikacji LUIS niezależnie od innych składników, jeśli przechowujesz ją we własnym repozytorium.

Aplikacja LUIS dla gałęzi głównej powinna mieć zastosowany schemat przechowywania wersji. Po scaleniu aktualizacji .lu aplikacji usługi LUIS z gałęzią główną zaimportujesz to zaktualizowane źródło do nowej wersji w aplikacji usługi LUIS dla gałęzi głównej.

Zaleca się użycie schematu przechowywania wersji liczbowych dla głównej wersji aplikacji usługi LUIS, na przykład:

major.minor[.build[.revision]]

Każda aktualizacja numeru wersji jest zwiększana o ostatnią cyfrę.

Główną/pomocniczą wersję można użyć do wskazania zakresu zmian funkcji aplikacji usługi LUIS:

• Wersja główna: znacząca zmiana, taka jak obsługa nowej intencji lub jednostki
• Wersja pomocnicza: zmiana pomocnicza zgodna z poprzednimi wersjami, taka jak po znaczącym nowym szkoleniu
• Kompilacja: Brak zmian funkcjonalności, tylko innej kompilacji.

Po określeniu numeru wersji dla najnowszej wersji głównej aplikacji USŁUGI LUIS należy skompilować i przetestować nową wersję aplikacji i opublikować ją w punkcie końcowym, w którym może być używana w różnych środowiskach kompilacji, takich jak Quality Assurance lub Production. Zdecydowanie zaleca się zautomatyzowanie wszystkich tych kroków w przepływie pracy ciągłej integracji.

Zobacz:

• Przepływy pracy automatyzacji zawierają szczegółowe informacje na temat implementowania przepływu pracy ciągłej integracji w celu testowania i wydawania aplikacji usługi LUIS.
• Usługa Release Management zawiera informacje na temat sposobu wdrażania aplikacji usługi LUIS.

Przechowywanie wersji aplikacji LUIS "feature branch"

Podczas pracy z aplikacją usługi LUIS utworzoną w celu obsługi pracy w gałęzi funkcji eksportujesz aplikację po zakończeniu pracy i dołączysz zaktualizowane 'lu żądanie ściągnięcia. Gałąź w repozytorium, a aplikacja usługi LUIS "dev branch" powinna zostać usunięta po scaleniu żądania ściągnięcia z gałęzią główną. Ponieważ ta aplikacja istnieje wyłącznie w celu obsługi pracy w gałęzi funkcji, nie ma określonego schematu przechowywania wersji, który należy zastosować w tej aplikacji.

Gdy zmiany w żądaniu ściągnięcia zostaną scalone z głównym, oznacza to, że należy zastosować przechowywanie wersji, aby wszystkie aktualizacje główne były wersjonowane niezależnie.

Następne kroki

• Dowiedz się więcej o testowaniu dla usługi LUIS DevOps
• Dowiedz się, jak zaimplementować metodyę DevOps dla usługi LUIS za pomocą usługi GitHub