Delen via

DevOps-procedures voor LUIS

  • Artikel

Belangrijk

LUIS wordt op 1 oktober 2025 buiten gebruik gesteld en vanaf 1 april 2023 kunt u geen nieuwe LUIS-resources meer maken. We raden u aan uw LUIS-toepassingen te migreren naar conversationele taalbegrip om te profiteren van doorlopende productondersteuning en meertalige mogelijkheden.

Softwaretechnici die een luis-app (Language Understanding) ontwikkelen, kunnen DevOps-procedures toepassen met betrekking tot broncodebeheer, geautomatiseerde builds, testen en releasebeheer door deze richtlijnen te volgen.

Broncodebeheer en vertakkingsstrategieën voor LUIS

Een van de belangrijkste factoren waarvan het succes van DevOps afhankelijk is, is broncodebeheer. Met een broncodebeheersysteem kunnen ontwikkelaars samenwerken aan code en wijzigingen bijhouden. Het gebruik van vertakkingen stelt ontwikkelaars in staat om te schakelen tussen verschillende versies van de codebasis en onafhankelijk van andere leden van het team te werken. Wanneer ontwikkelaars een pull-aanvraag (PR) indienen om updates van de ene vertakking naar de andere voor te stellen, of wanneer wijzigingen worden samengevoegd, kunnen dit de trigger zijn voor geautomatiseerde builds om code te bouwen en continu te testen.

Met behulp van de concepten en richtlijnen die in dit document worden beschreven, kunt u een LUIS-app ontwikkelen tijdens het bijhouden van wijzigingen in een broncodebeheersysteem en deze aanbevolen procedures voor software-engineering volgen:

  • Broncodebeheer

    • De broncode voor uw LUIS-app heeft een door mensen leesbare indeling.
    • Het model kan op een herhaalbare manier worden gebouwd op basis van de bron.
    • De broncode kan worden beheerd door een broncodeopslagplaats.
    • Referenties en geheimen, zoals sleutels, worden nooit opgeslagen in de broncode.

  • Vertakken en samenvoegen

    • Ontwikkelaars kunnen vanuit onafhankelijke vertakkingen werken.
    • Ontwikkelaars kunnen in meerdere vertakkingen tegelijk werken.
    • Het is mogelijk om wijzigingen in een LUIS-app van de ene vertakking in de andere te integreren via rebase of samenvoeging.
    • Ontwikkelaars kunnen een pull-aanvraag samenvoegen met de bovenliggende vertakking.

  • Versiebeheer

    • Elk onderdeel in een grote toepassing moet onafhankelijk van een versie worden gemaakt, zodat ontwikkelaars wijzigingen of updates die fouten veroorzaken, kunnen detecteren door alleen het versienummer te bekijken.

  • Codebeoordelingen

    • De wijzigingen in de pull-aanvraag worden weergegeven als door mensen leesbare broncode die kan worden gecontroleerd voordat de pull-aanvraag wordt geaccepteerd.

Broncodebeheer

Als u de definitie van het app-schema van een LUIS-app in een broncodebeheersysteem wilt behouden, gebruikt u de LUDown-indeling (.lu) van de app. .lu indeling heeft de voorkeur boven .json indeling omdat deze door mensen kan worden gelezen, waardoor het gemakkelijker is om wijzigingen in pull-aanvragen aan te brengen en te controleren.

Een LUIS-app opslaan met de LUDown-indeling

Een LUIS-app opslaan in .lu de indeling en deze onder broncodebeheer plaatsen:

  • OF: exporteer de app-versie.lu vanuit de LUIS-portal en voeg deze toe aan uw opslagplaats voor broncodebeheer

  • OF: Een teksteditor gebruiken om een .lu bestand voor een LUIS-app te maken en dit toe te voegen aan uw opslagplaats voor broncodebeheer

Tip

Als u met de JSON-export van een LUIS-app werkt, kunt u deze converteren naar LUDown. Gebruik de --sort optie om ervoor te zorgen dat intenties en uitingen alfabetisch worden gesorteerd.
Houd er rekening mee dat de . Met de ingebouwde LU-exportmogelijkheid in de LUIS-portal wordt de uitvoer al gesorteerd.

De LUIS-app bouwen vanuit de bron

Voor een LUIS-app betekent bouwen op basis van brondat u een nieuwe LUIS-app-versie maakt door de .lu bron te importeren , om de versie te trainen en deze te publiceren. U kunt dit doen in de LUIS-portal of via de opdrachtregel:

Bestanden die moeten worden onderhouden onder broncodebeheer

De volgende typen bestanden voor uw LUIS-toepassing moeten worden onderhouden onder broncodebeheer:

Referenties en sleutels zijn niet ingecheckt

Neem geen sleutels of vergelijkbare vertrouwelijke waarden op in bestanden die u incheckt in uw opslagplaats, waar ze mogelijk zichtbaar zijn voor onbevoegd personeel. De sleutels en andere waarden die u het inchecken moet voorkomen, zijn onder andere:

  • LUIS-creatie- en voorspellingssleutels
  • LUIS-ontwerp- en voorspellingseindpunten
  • Azure-resourcesleutels
  • Toegangstokens, zoals het token voor een Azure-service-principal die wordt gebruikt voor automatiseringsverificatie

Strategieën voor het veilig beheren van geheimen

Strategieën voor het veilig beheren van geheimen zijn onder andere:

  • Als u git-versiebeheer gebruikt, kunt u runtimegeheimen opslaan in een lokaal bestand en voorkomen dat het bestand wordt ingecheckt door een patroon toe te voegen dat overeenkomt met de bestandsnaam van een .gitignore-bestand
  • In een automatiseringswerkstroom kunt u geheimen veilig opslaan in de parametersconfiguratie die wordt aangeboden door die automatiseringstechnologie. Als u bijvoorbeeld GitHub Actions gebruikt, kunt u geheimen veilig opslaan in GitHub-geheimen.

Vertakken en samenvoegen

Gedistribueerde versiebeheersystemen zoals Git bieden flexibiliteit in de wijze waarop teamleden codewijzigingen publiceren, delen, controleren en herhalen via ontwikkelingsvertakkingen die met anderen worden gedeeld. Gebruik een Git-vertakkingsstrategie die geschikt is voor uw team.

Welke vertakkingsstrategie u ook kiest, een belangrijk principe van allemaal is dat teamleden onafhankelijk van het werk dat in andere vertakkingen wordt uitgevoerd, aan de oplossing kunnen werken binnen een functievertakking .

Onafhankelijk werken in vertakkingen met een LUIS-project ondersteunen:

  • De hoofdbranch heeft een eigen LUIS-app. Deze app vertegenwoordigt de huidige status van uw oplossing voor uw project en de huidige actieve versie moet altijd worden toegewezen aan de .lu bron in de hoofdbranch. Alle updates voor de .lu bron voor deze app moeten worden gecontroleerd en getest, zodat deze app op elk gewenst moment kan worden geïmplementeerd in buildomgevingen zoals Productie. Wanneer updates naar de .lu worden samengevoegd met main vanuit een functiebranch, moet u een nieuwe versie maken in de LUIS-app en het versienummer verhogen.

  • Elke functiebranch moet een eigen exemplaar van een LUIS-app gebruiken. Ontwikkelaars werken met deze app in een functiebranch zonder dat dit gevolgen heeft voor ontwikkelaars die in andere vertakkingen werken. Deze app 'dev branch' is een werkende kopie die moet worden verwijderd wanneer de functiebranch wordt verwijderd.

Git-functiebranch

Ontwikkelaars kunnen werken vanuit onafhankelijke vertakkingen

Ontwikkelaars kunnen onafhankelijk van andere vertakkingen aan updates voor een LUIS-app werken door:

  1. Een functiebranch maken op basis van de hoofdbranch (afhankelijk van uw vertakkingsstrategie, meestal hoofd- of ontwikkelstrategie).

  2. Maak een nieuwe LUIS-app in de LUIS-portal (de 'dev branch app') uitsluitend ter ondersteuning van het werk in de functiebranch.

    • Als de .lu bron voor uw oplossing al in uw vertakking bestaat, omdat deze is opgeslagen na werk dat eerder in het project in een andere vertakking is uitgevoerd, maakt u de LUIS-app voor de ontwikkelaarsvertakking door het .lu bestand te importeren.

    • Als u aan een nieuw project begint te werken, hebt u de .lu bron voor uw hoofd-LUIS-app nog niet in de opslagplaats. U maakt het .lu bestand door uw dev branch-app vanuit de portal te exporteren wanneer u uw functiebranchwerk hebt voltooid en dient het in als onderdeel van uw pull-aanvraag.

  3. Werk aan de actieve versie van uw dev branch-app om de vereiste wijzigingen te implementeren. U wordt aangeraden slechts in één versie van uw dev branch-app te werken voor al het werk van de functiebranch. Als u meer dan één versie in uw dev branch-app maakt, moet u bijhouden welke versie de wijzigingen bevat die u wilt inchecken wanneer u uw pull-aanvraag indient.

  4. De updates testen: zie Testen voor LUIS DevOps voor meer informatie over het testen van uw dev branch-app.

  5. Exporteer de actieve versie van uw dev branch-app vanuit .lu de lijst met versies.

  6. Controleer uw updates en nodig een peer review van uw updates uit. Als u GitHub gebruikt, moet u een pull-aanvraag indienen.

  7. Wanneer de wijzigingen zijn goedgekeurd, voegt u de updates samen met de hoofdbranch. Op dit moment maakt u een nieuwe versie van de hoofd-LUIS-app, met behulp van de bijgewerkte .lu in main. Zie Versiebeheer voor overwegingen bij het instellen van de versienaam.

  8. Wanneer de functiebranch wordt verwijderd, is het een goed idee om de LUIS-app dev branch te verwijderen die u hebt gemaakt voor het werk van de functiebranch.

Ontwikkelaars kunnen tegelijkertijd in meerdere vertakkingen werken

Als u het patroon volgt dat hierboven wordt beschreven in Ontwikkelaars kunnen werken vanuit onafhankelijke vertakkingen, gebruikt u een unieke LUIS-toepassing in elke functiebranch. Eén ontwikkelaar kan tegelijkertijd aan meerdere vertakkingen werken, zolang deze overschakelt naar de juiste DEV Branch LUIS-app voor de vertakking waaraan ze momenteel werken.

U wordt aangeraden dezelfde naam te gebruiken voor zowel de functiebranch als voor de LUIS-app dev branch die u voor het werk van de functiebranch maakt, zodat de kans kleiner is dat u per ongeluk met de verkeerde app werkt.

Zoals hierboven vermeld, raden we u aan om voor het gemak in één versie in elke dev branch-app te werken. Als u meerdere versies gebruikt, moet u ervoor zorgen dat u de juiste versie activeert wanneer u schakelt tussen dev branch-apps.

Meerdere ontwikkelaars kunnen gelijktijdig aan dezelfde vertakking werken

U kunt meerdere ontwikkelaars ondersteunen die tegelijkertijd aan dezelfde functiebranch werken:

  • Ontwikkelaars bekijken dezelfde functiebranch en push- en pull-wijzigingen die door zichzelf en andere ontwikkelaars zijn ingediend terwijl het werk doorgaat, zoals normaal.

  • Als u het patroon volgt dat hierboven wordt beschreven in Ontwikkelaars kunnen werken vanuit onafhankelijke vertakkingen, gebruikt deze vertakking een unieke LUIS-toepassing om ontwikkeling te ondersteunen. De LUIS-app dev branch wordt gemaakt door het eerste lid van het ontwikkelteam dat begint te werken in de functiebranch.

  • Teamleden toevoegen als inzenders aan de LUIS-app dev branch.

  • Wanneer het functievertakkingswerk is voltooid, exporteert u de actieve versie van de LUIS-app dev branch vanuit .lu de lijst met versies, slaat u het bijgewerkte .lu bestand op in de opslagplaats en controleert u de wijzigingen en controleert u de wijzigingen.

Wijzigingen van de ene vertakking in een andere opnemen met herbase of samenvoeging

Sommige andere ontwikkelaars in uw team die in een andere vertakking werken, hebben mogelijk updates aangebracht in de .lu bron en ze samengevoegd met de hoofdbranch nadat u de functiebranch hebt gemaakt. U kunt de wijzigingen in uw werkversie opnemen voordat u zelf wijzigingen aanbrengt in uw functiebranch. U kunt dit doen door de basis te herstellen of samen te voegen naar main op dezelfde manier als elke andere code-asset. Omdat de LUIS-app in LUDown-indeling door mensen kan worden gelezen, ondersteunt deze samenvoegen met behulp van standaard samenvoegingshulpprogramma's.

Volg deze tips als u uw LUIS-app opnieuw in een functievertakking installeert:

  • Voordat u de basis wijzigt of samenvoegt, moet u ervoor zorgen dat uw lokale kopie van de .lu bron voor uw app alle meest recente wijzigingen bevat die u hebt toegepast met behulp van de LUIS-portal. Exporteer uw app eerst opnieuw vanuit de portal. Op die manier kunt u ervoor zorgen dat wijzigingen die u in de portal hebt aangebracht en die u nog niet hebt geëxporteerd, niet verloren gaan.

  • Gebruik tijdens het samenvoegen standaardhulpprogramma's om samenvoegingsconflicten op te lossen.

  • Vergeet niet nadat de basis opnieuw is gebaseerd of samenvoegen is voltooid om de app opnieuw te importeren in de portal, zodat u met de bijgewerkte app werkt terwijl u uw eigen wijzigingen blijft toepassen.

Pull-aanvragen samenvoegen

Nadat uw pull-aanvraag is goedgekeurd, kunt u uw wijzigingen samenvoegen in uw hoofdbranch. Er zijn geen speciale overwegingen van toepassing op de LUDown-bron voor een LUIS-app: deze is voor mensen leesbaar en ondersteunt daarom samenvoegen met behulp van standaard samenvoegingshulpprogramma's. Eventuele samenvoegingsconflicten kunnen op dezelfde manier worden opgelost als met andere bronbestanden.

Nadat uw pull-aanvraag is samengevoegd, is het raadzaam om het volgende op te ruimen:

  • De vertakking in uw opslagplaats verwijderen

  • Verwijder de LUIS-app 'dev branch' die u hebt gemaakt voor het functiebranchwerk.

Op dezelfde manier als bij toepassingscodeassets, moet u eenheidstests schrijven om luis-app-updates te begeleiden. U moet werkstromen voor continue integratie gebruiken om het volgende te testen:

  • Updates in een pull-aanvraag voordat de pull-aanvraag wordt samengevoegd
  • De LUIS-app van de hoofdbranch nadat een pull-aanvraag is goedgekeurd en de wijzigingen zijn samengevoegd met main.

Zie Testen voor DevOps voor LUIS voor meer informatie over het testen voor LUIS DevOps. Zie Automation-werkstromen voor LUIS DevOps voor meer informatie over het implementeren van werkstromen.

Codebeoordelingen

Een LUIS-app in LUDown-indeling is door mensen leesbaar en ondersteunt de communicatie van wijzigingen in een pull-aanvraag die geschikt is voor revisie. Eenheidstestbestanden zijn ook geschreven in LUDown-indeling en kunnen ook eenvoudig worden beoordeeld in een pull-aanvraag.

Versiebeheer

Een toepassing bestaat uit meerdere onderdelen die zaken kunnen bevatten, zoals een bot die wordt uitgevoerd in Azure AI Bot Service, QnA Maker, Azure AI Speech-service en meer. Als u het doel van losjes gekoppelde toepassingen wilt bereiken, gebruikt u versiebeheer , zodat elk onderdeel van een toepassing onafhankelijk van elkaar wordt geversied, zodat ontwikkelaars belangrijke wijzigingen of updates kunnen detecteren door naar het versienummer te kijken. Het is eenvoudiger om uw LUIS-app onafhankelijk van andere onderdelen te versien als u deze in een eigen opslagplaats onderhoudt.

Voor de LUIS-app voor de hoofdvertakking moet een versiebeheerschema worden toegepast. Wanneer u updates voor de .lu voor een LUIS-app samenvoegt in main, importeert u die bijgewerkte bron vervolgens in een nieuwe versie in de LUIS-app voor de hoofdbranch.

U wordt aangeraden een numeriek versiebeheerschema te gebruiken voor de hoofdversie van de LUIS-app, bijvoorbeeld:

major.minor[.build[.revision]]

Bij elke update wordt het versienummer verhoogd naar het laatste cijfer.

De primaire/secundaire versie kan worden gebruikt om het bereik van de wijzigingen in de functionaliteit van de LUIS-app aan te geven:

  • Primaire versie: een belangrijke wijziging, zoals ondersteuning voor een nieuwe intentie of entiteit
  • Secundaire versie: een achterwaarts compatibele kleine wijziging, zoals na een belangrijke nieuwe training
  • Build: Geen functionaliteitswijziging, alleen een andere build.

Zodra u het versienummer voor de meest recente revisie van uw LUIS-hoofd-app hebt bepaald, moet u de nieuwe app-versie bouwen en testen en deze publiceren naar een eindpunt waar deze kan worden gebruikt in verschillende buildomgevingen, zoals Kwaliteitsborging of Productie. Het wordt ten zeerste aanbevolen om al deze stappen in een CI-werkstroom (continue integratie) te automatiseren.

Zie:

  • Automatiseringswerkstromen voor meer informatie over het implementeren van een CI-werkstroom om een LUIS-app te testen en vrij te geven.
  • Releasebeheer voor informatie over het implementeren van uw LUIS-app.

Versiebeheer voor de LUIS-app 'functievertakking'

Wanneer u werkt met een LUIS-app 'dev branch' die u hebt gemaakt ter ondersteuning van werk in een functiebranch, exporteert u uw app wanneer uw werk is voltooid en neemt u de bijgewerkte 'lu op in uw pull-aanvraag. De vertakking in uw opslagplaats en de LUIS-app 'dev branch' moeten worden verwijderd nadat de pull-aanvraag is samengevoegd met main. Omdat deze app uitsluitend bestaat ter ondersteuning van het werk in de functievertakking, is er geen specifiek versiebeheerschema dat u binnen deze app hoeft toe te passen.

Wanneer uw wijzigingen in uw pull-aanvraag worden samengevoegd met de hoofdversie, moet de versiebeheer worden toegepast, zodat alle updates voor de hoofdversie onafhankelijk van elkaar worden uitgevoerd.

Volgende stappen