Metodyki DevOps dla usługi LUIS

  • Artykuł

Ważne

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

Inżynierowie oprogramowania, którzy opracowują aplikację Language Understanding (LUIS), mogą stosować praktyki 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 powodzenie 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 pracę 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ć na podstawie ź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ć jednocześnie w wielu gałęziach.
    • Istnieje możliwość zintegrowania zmian w aplikacji usługi LUIS z jednej gałęzi z innej za pomocą bazy 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, co umożliwia deweloperom wykrywanie przełomowych zmian lub aktualizacji tylko przez zapoznanie się z numerem 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:

Porada

Jeśli pracujesz z eksportem JSON aplikacji usługi LUIS, możesz przekonwertować ją na kod 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 , utwórz nową wersję aplikacji usługi LUIS, importując .lu źródło , aby wytrenować wersję i opublikować ją. Można to zrobić w portalu usługi LUIS lub w wierszu polecenia:

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

W ramach kontroli źródła powinny być przechowywane następujące typy plików dla aplikacji luis:

Poświadczenia i klucze nie są zaewidencjonowane

Nie dołączaj kluczy ani podobnych wartości poufnych do plików zaewidencjonowanych w repozytorium, gdzie mogą być widoczne dla nieautoryzowanego personelu. Klucze i inne wartości, których nie można zaewidencjonować, 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 wpisy tajne można bezpiecznie przechowywać w konfiguracji parametrów oferowanych przez technologię automatyzacji. Jeśli na przykład używasz 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ądania i iterowania zmian w kodzie za pośrednictwem gałęzi programistycznych udostępnianych innym osobom. Zastosuj strategię rozgałęziania Git , która jest odpowiednia 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 dla tej aplikacji należy przejrzeć i przetestować, 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 wyprzeć 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.

Gałąź funkcji usługi Git

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 dev branch dla wszystkich elementów roboczych gałęzi funkcji. Jeśli tworzysz więcej niż jedną wersję w aplikacji 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. Testowanie aktualizacji — zobacz Testowanie usługi LUIS DevOps , aby uzyskać szczegółowe informacje na temat testowania aplikacji dev branch.

  5. Wyeksportuj aktywną wersję aplikacji dev branch zgodnie .lu z listą wersji.

  6. Zaewidencjonuj aktualizacje i zaproś element równorzędny do przeglądu 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 aktualizacji .lu w głównej wersji. Zobacz Przechowywanie wersji , aby zapoznać się z zagadnieniami dotyczącymi ustawiania nazwy wersji.

  8. Gdy gałąź funkcji zostanie usunięta, dobrym pomysłem jest usunięcie aplikacji luis dev branch utworzonej na potrzeby pracy gałęzi funkcji.

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

Jeśli postępujesz 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ć jednocześnie nad wieloma gałęziami, o ile przełączają się do właściwej aplikacji usługi LUIS w gałęzi dewelopera dla gałęzi, nad którą obecnie pracują.

Zalecamy użycie tej samej nazwy zarówno dla gałęzi funkcji, jak i dla aplikacji LUIS w gałęzi dewelopera 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 dewelopera. Jeśli używasz wielu wersji, należy aktywować poprawną wersję podczas przełączania się między aplikacjami deweloperskimi.

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 pracy, jak zwykle.

  • Jeśli postępujesz 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 LUIS "dev branch" zostanie utworzona przez pierwszego członka zespołu deweloperskiego, który rozpoczyna 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 LUIS gałęzi dewelopera jako .lu z listy wersji, zapisz zaktualizowany .lu plik w repozytorium i zaewidencjonuj zmiany i zaewidencjonuj je.

Dołączanie zmian z jednej gałęzi do innej z bazą lub scalanie

Niektórzy inni deweloperzy w zespole pracujący w innej gałęzi mogli wprowadzić aktualizacje do .lu źródła i scalić je z gałęzią główną po utworzeniu gałęzi funkcji. Przed kontynuowanie wprowadzania własnych zmian w gałęzi funkcji może być konieczne dołączenie ich do wersji roboczej. Można to zrobić, ponownie bazując lub scalając je z elementem głównym w taki sam sposób jak dowolny 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 korzystasz z aplikacji usługi LUIS w gałęzi funkcji:

  • Przed ponownym bazą danych lub scalania upewnij się, że lokalna kopia .lu źródła aplikacji zawiera wszystkie najnowsze zmiany zastosowane przy użyciu portalu usługi LUIS, najpierw eksportując aplikację z portalu. W ten sposób możesz upewnić się, że wszelkie zmiany wprowadzone w portalu i nie zostały jeszcze wyeksportowane, nie zostaną utracone.

  • Podczas scalania użyj standardowych narzędzi do rozwiązywania konfliktów scalania.

  • Nie zapomnij po zakończeniu ponownej bazy danych lub scalania, aby ponownie zaimportować aplikację z powrotem do portalu, aby pracować 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ą. Nie ma specjalnych zagadnień dotyczących źródła LUDown dla aplikacji usługi LUIS: jest czytelna dla człowieka, dlatego obsługuje scalanie przy użyciu standardowych narzędzi scalania. Wszystkie 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ę LUIS "dev branch" utworzoną dla 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. Do testowania należy zastosować przepływy pracy ciągłej integracji:

  • Aktualizacje żądania ściągnięcia przed scaleniem żądania ściągnięcia
  • Aplikacja 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 dla metodyki DEVOps usługi LUIS, 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.

Przechowywanie wersji

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, Azure AI Speech Service i inne. Aby osiągnąć cel luźno powiązanych aplikacji, należy użyć kontroli wersji , aby każdy składnik aplikacji był niezależnie wersjonowany, umożliwiając deweloperom wykrywanie zmian powodujących niezgodność lub aktualizacji tylko przez przyjrzenie się numerowi wersji. Łatwiej jest wersję 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 aplikacji usługi LUIS z .lu aplikacją główną zaimportujesz to zaktualizowane źródło do nowej wersji w aplikacji LUIS dla gałęzi głównej.

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

major.minor[.build[.revision]]

Każda aktualizacja numeru wersji jest zwiększana w ostatniej cyfrze.

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: pomocnicza zmiana zgodna z poprzednimi wersjami, taka jak po znaczącym nowym treningu
  • Kompilacja: brak zmian funkcjonalności, tylko innej kompilacji.

Po określeniu numeru wersji dla najnowszej wersji głównej aplikacji 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.
  • Release Management, aby uzyskać informacje na temat 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 uwzględnisz zaktualizowaną 'lu w żądaniu ściągnięcia. Gałąź w repozytorium i aplikacja LUIS "dev branch" powinna zostać usunięta po scaleniu żądania ściągnięcia z głównym. 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 są scalane z główną wersją, oznacza to, że należy zastosować przechowywanie wersji, tak aby wszystkie aktualizacje główne były obsługiwane niezależnie.

Następne kroki