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 maken. We raden u aan uw LUIS-toepassingen te migreren naar gesprekstaalbegrip om te profiteren van continue productondersteuning en meertalige mogelijkheden.

Softwaretechnici die een LUIS-app (Language Understanding) ontwikkelen, kunnen DevOps-procedures toepassen op 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. Met het gebruik van vertakkingen kunnen ontwikkelaars schakelen tussen verschillende versies van de codebasis en onafhankelijk van andere leden van het team 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, kan 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 de volgende aanbevolen procedures voor software-engineering volgen:

  • Broncodebeheer

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

  • Vertakking en samenvoegen

    • Ontwikkelaars kunnen vanuit onafhankelijke vertakkingen werken.
    • Ontwikkelaars kunnen gelijktijdig in meerdere vertakkingen werken.
    • Het is mogelijk om wijzigingen in een LUIS-app vanuit de ene vertakking te integreren in een andere vertakking door opnieuw tebaseen of samen te voegen.
    • Ontwikkelaars kunnen een pull-aanvraag samenvoegen met de bovenliggende vertakking.

  • Versiebeheer

    • Elk onderdeel in een grote toepassing moet onafhankelijk van elkaar worden geversied, zodat ontwikkelaars belangrijke wijzigingen of updates kunnen detecteren door naar het versienummer te kijken.

  • Codebeoordelingen

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

Bronbeheer

Als u de definitie van het app-schema van een LUIS-app in een broncodebeheersysteem wilt onderhouden, gebruikt u de LUDown-indeling (.lu) voor de app. .lu indeling heeft de voorkeur voor .json indeling, omdat deze leesbaar is voor mensen, waardoor het eenvoudiger is om wijzigingen in PULL's aan te brengen en te controleren.

Een LUIS-app opslaan met de LUDown-indeling

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

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

  • OF: Gebruik een teksteditor om een .lu bestand voor een LUIS-app te maken en 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 lu-exportfunctionaliteit die is ingebouwd in de LUIS-portal, wordt de uitvoer al gesorteerd.

De LUIS-app bouwen vanuit de bron

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

Bestanden die moeten worden onderhouden onder broncodebeheer

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

  • .lu bestand voor de LUIS-toepassing

  • Definitiebestanden voor eenheidstests (uitingen en verwachte resultaten)

  • Batch-testbestanden (uitingen en verwachte resultaten) die worden gebruikt voor het testen van prestaties

Referenties en sleutels worden 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 moet voorkomen, zijn onder andere:

  • LUIS-ontwerp- 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:

  • Als u Git-versiebeheer gebruikt, kunt u runtimegeheimen opslaan in een lokaal bestand en het inchecken van het bestand voorkomen door een patroon toe te voegen dat overeenkomt met de bestandsnaam met een .gitignore-bestand
  • In een automatiseringswerkstroom kunt u geheimen veilig opslaan in de parametersconfiguratie die door die automatiseringstechnologie wordt aangeboden. 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, beoordelen en herhalen via ontwikkelingsvertakkingen die met anderen worden gedeeld. Stel een Git-vertakkingsstrategie in 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.

Ondersteuning voor onafhankelijk werken in vertakkingen met een LUIS-project:

  • 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 die zich in de hoofdbranch bevindt. 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 voor het bouwen van omgevingen zoals Productie. Wanneer updates voor de onderdelen worden samengevoegd in de .lu hoofdversie van een functiebranch, moet u een nieuwe versie maken in de LUIS-app en het versienummer op stoten.

  • Elke functiebranch moet een eigen exemplaar van een LUIS-app gebruiken. Ontwikkelaars werken met deze app in een functiebranch zonder dat ze het risico lopen dat ze in andere vertakkingen werken. Deze dev branch-app 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 vanuit 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 bestaat in uw vertakking, omdat deze is opgeslagen nadat deze eerder in het project is uitgevoerd in een andere vertakking, maakt u de LUIS-app voor de dev-vertakking door het .lu bestand te importeren.

    • Als u aan een nieuw project begint, beschikt u nog niet over de .lu bron voor uw hoofd-LUIS-app in de opslagplaats. U maakt het .lu bestand door uw dev branch-app vanuit de portal te exporteren wanneer u het werk van de functiebranch hebt voltooid en het in te dienen 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 functiebranchwerk. Als u meer dan één versie in uw dev Branch-app maakt, moet u ervoor zorgen dat u bijhoudt welke versie de wijzigingen bevat die u wilt inchecken wanneer u uw pull-aanvraag verhoogt.

  4. Test de updates. 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 op basis .lu van de versieslijst.

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

  7. Wanneer de wijzigingen zijn goedgekeurd, voegt u de updates samen in de hoofdbranch. Op dit moment maakt u een nieuwe versie van de hoofd-LUIS-app met behulp van de bijgewerkte hoofd-APP.lu. 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 van de dev-vertakking te verwijderen die u hebt gemaakt voor het werk van de functiebranch.

Ontwikkelaars kunnen gelijktijdig in meerdere vertakkingen werken

Als u het bovenstaande patroon in Ontwikkelaars volgt, kunt u vanuit onafhankelijke vertakkingen werken, dan gebruikt u een unieke LUIS-toepassing in elke functiebranch. Eén ontwikkelaar kan gelijktijdig aan meerdere vertakkingen werken, zolang ze overschakelen naar de juiste LUIS-app voor dev branch voor de vertakking waaraan ze momenteel werken.

U wordt aangeraden dezelfde naam te gebruiken voor zowel de functiebranch als voor de LUIS-app van de dev-vertakking die u voor de functiebranch maakt, zodat u minder waarschijnlijk aan de verkeerde app werkt.

Zoals hierboven vermeld, raden we u aan om eenvoudig te werken in één versie in elke dev branch-app. 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:

Wijzigingen van de ene vertakking in een andere vertakking opnemen met opnieuwbase of samenvoegen

Sommige andere ontwikkelaars in uw team die in een andere vertakking werken, hebben mogelijk updates aangebracht in de .lu bron en samengevoegd met de hoofdbranch nadat u de functiebranch hebt gemaakt. U kunt hun wijzigingen opnemen in uw werkende versie voordat u zelf wijzigingen aanbrengt in uw functiebranch. U kunt dit doen door opnieuw tebaseen of samen te voegen op dezelfde manier als andere codeassets. Omdat de LUIS-app in LUDown-indeling voor mensen leesbaar is, ondersteunt het samenvoegen met behulp van standaard samenvoeghulpprogramma's.

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

  • Voordat u een nieuwe basis maakt 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 door uw app eerst opnieuw te exporteren vanuit de portal. Op die manier kunt u ervoor zorgen dat wijzigingen die u in de portal hebt aangebracht en nog niet geëxporteerd, niet verloren gaan.

  • Gebruik tijdens de samenvoegbewerking standaardhulpprogramma's om samenvoegingsconflicten op te lossen.

  • Vergeet niet dat u de app opnieuw importeert in de portal nadat de nieuwe basis of samenvoeging is voltooid, 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 met uw hoofdbranch. Er zijn geen speciale overwegingen van toepassing op de LUDown-bron voor een LUIS-app: deze kan door mensen worden gelezen en biedt dus ondersteuning voor samenvoegen met behulp van standaardhulpprogramma's voor samenvoegen. Eventuele samenvoegingsconflicten kunnen op dezelfde manier worden opgelost als bij 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 voor het bijwerken van LUIS-apps. 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 voor de hoofdbranch nadat een pull-aanvraag is goedgekeurd en de wijzigingen zijn samengevoegd in de hoofdmap.

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

Codebeoordelingen

Een LUIS-app in LUDown-indeling is leesbaar voor mensen, die ondersteuning biedt voor de communicatie van wijzigingen in een pull-aanvraag die geschikt is voor beoordeling. Eenheidstestbestanden worden ook geschreven in LUDown-indeling en kunnen ook eenvoudig worden beoordeeld in een pull-aanvraag.

Versiebeheer

Een toepassing bestaat uit meerdere onderdelen, 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 alleen het versienummer te bekijken. 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 zijn toegepast. Wanneer u updates voor een LUIS-app samenvoegt in de .lu hoofdversie, importeert u die bijgewerkte bron vervolgens in een nieuwe versie in de LUIS-app voor de hoofdbranch.

Het wordt aanbevolen om een numeriek versiebeheerschema te gebruiken voor de hoofdversie van de LUIS-app, bijvoorbeeld:

major.minor[.build[.revision]]

Elke update van het versienummer wordt verhoogd op 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 secundaire wijziging die compatibel is met eerdere versies, zoals na belangrijke nieuwe training
  • Build: Geen functionaliteitswijziging, slechts een andere build.

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

Zie:

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

De LUIS-app 'Functievertakking' versieren

Wanneer u werkt met een LUIS-app voor ontwikkelaarsbranch die u hebt gemaakt om werk in een functiebranch te ondersteunen, exporteert u uw app wanneer uw werk is voltooid en neemt u de bijgewerkte versie 'lu op in uw pull-aanvraag. De vertakking in uw opslagplaats en de LUIS-app dev branch moet worden verwijderd nadat de pull-aanvraag is samengevoegd in de hoofdmap. Omdat deze app alleen bestaat ter ondersteuning van het werk in de functievertakking, is er geen specifiek versiebeheerschema dat u in deze app moet toepassen.

Wanneer uw wijzigingen in uw pull-aanvraag worden samengevoegd in de hoofdmap, moet de versiebeheer worden toegepast, zodat alle updates naar de hoofdversie onafhankelijk van elkaar worden bijgewerkt.

Volgende stappen