DevOps-procedures voor LUIS

  • Artikel
  • 12 minuten om te lezen

Softwaretechnici die een Language Understanding (LUIS)-app ontwikkelen, kunnen DevOps-procedures toepassen op het gebied van broncodebeheer, geautomatiseerde builds,testen en releasebeheer door deze richtlijnen te volgen.

Broncodebeheer en vertakkingsstrategieën voor LUIS

Een van de belangrijkste factoren waar het succes van DevOps van 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, kunnen deze 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 best practices voor software-engineering volgen:

  • Broncodebeheer

    • De broncode voor uw LUIS-app heeft een door mensen 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 ontwerp- en abonnementssleutels, worden nooit opgeslagen in de broncode.

  • Vertakking en samenvoeging

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

  • Versiebeheer

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

  • Codebeoordelingen

    • De wijzigingen in de pr worden gepresenteerd als door mensen leesbare broncode die kan worden gecontroleerd voordat de pr wordt geaccepteerd.

Broncodebeheer

Als u de app-schemadefinitie van een LUIS-app in een broncodebeheersysteem wilt behouden, gebruikt u de LUDown-indeling ( .lu ) weergave van de app. .lu indeling heeft de voorkeur boven opmaak, omdat deze door mensen kan worden gelezen, waardoor het eenvoudiger is om wijzigingen in PR's aan te brengen .json en te controleren.

Een LUIS-app opslaan met de LUDown-indeling

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

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

  • OF: Gebruik een teksteditor om een bestand voor een LUIS-app te maken .lu en dit toe te voegen aan uw broncodebeheeropslagplaats

Tip

Als u met de JSON-export van een LUIS-app werkt, kunt u deze converteren naar LUDown. Gebruik de optie om ervoor te zorgen dat intenties en --sort utterances alfabetisch worden gesorteerd.
Houd er rekening mee dat de . Lu-exportfunctie die is ingebouwd in de LUIS-portal, sorteert de uitvoer al.

De LUIS-app bouwen op basis van de bron

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

  • Gebruik de LUIS-portal om de versie .lu van de app te importeren uit broncodebeheer en de app te trainen en te publiceren.

  • Gebruik de Bot Framework-opdrachtregelinterface voor LUIS op de opdrachtregel of in een CI/CD-werkstroom om de versie van de app vanuit broncodebeheer te importeren in een LUIS-toepassing en de app te trainen en te .lu publiceren.

Te onderhouden bestanden onder broncodebeheer

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

Referenties en sleutels zijn niet ingecheckt

Neem geen abonnementssleutels of vergelijkbare vertrouwelijke waarden op in bestanden die u incheckt bij uw repo waar ze mogelijk zichtbaar zijn voor niet-geautoriseerd personeel. De sleutels en andere waarden die u moet verhinderen om in te checken, zijn onder andere:

  • Luis-ontwerp- en voorspellingssleutels
  • Luis-eindpunten voor ontwerp en voorspelling
  • Azure-abonnementssleutels
  • 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 inchecken van het bestand voorkomen door een patroon toe te voegen dat de bestandsnaam aan een .gitignore-bestand koppelt
  • In een automatiseringswerkstroom kunt u geheimen veilig opslaan in de parametersconfiguratie die door die automatiseringstechnologie wordt aangeboden. Als u bijvoorbeeld acties GitHub gebruikt,kunt u geheimen veilig opslaan in GitHub geheimen.

Vertakking en samenvoeging

Gedistribueerde versiebeheersystemen zoals Git bieden flexibiliteit in de manier waarop teamleden codewijzigingen publiceren, delen, beoordelen en itereren via ontwikkelingsvertakkingen die met anderen worden gedeeld. Een Git-vertakkingsstrategie aannemen die geschikt is voor uw team.

Welke vertakkingsstrategie u ook gebruikt, een belangrijk principe van al deze vertakkingen is dat teamleden onafhankelijk van het werk dat in andere vertakkingen wordt gedaan, aan de oplossing kunnen werken binnen een functievertakking.

Ter ondersteuning van onafhankelijk werken in vertakkingen met een LUIS-project:

  • De main branch 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 toe te staan aan de bron die zich in de .lu main branch. Alle updates voor de bron voor deze app moeten worden gecontroleerd en getest, zodat deze app op elk moment kan worden geïmplementeerd voor het bouwen van omgevingen zoals .lu Productie. Wanneer updates voor de worden samengevoegd in main vanuit een functievertakking, moet u een nieuwe versie maken in de .lu LUIS-app en het versienummer oprekken.

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

Git-functiebranche

Ontwikkelaars kunnen werken vanuit onafhankelijke vertakkingen

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

  1. Het maken van een functievertakking main branch (afhankelijk van uw vertakkingsstrategie, meestal hoofdvertakking of ontwikkelen).

  2. Maak een nieuwe LUIS-app in de LUIS-portal (de 'dev branch-app') die alleen ondersteuning biedt voor het werk in de functiebranche.

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

    • Als u aan een nieuw project begint, hebt u nog niet de bron voor uw .lu luis-app in de repo. U maakt het bestand door uw dev branch-app vanuit de portal te exporteren wanneer u uw functievertakkingswerk hebt voltooid en dit als onderdeel van uw pr .lu te verzenden.

  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 alle functies in de vertakking. Als u meer dan één versie in uw dev branch-app maakt, moet u ervoor zorgen dat u bij houdt welke versie de wijzigingen bevat die u wilt inchecken wanneer u uw pr indient.

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

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

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

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

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

Ontwikkelaars kunnen in meerdere vertakkingen tegelijk werken

Als u het patroon volgt dat hierboven wordt beschreven in Ontwikkelaarskunnen werken vanuit onafhankelijke vertakkingen, gebruikt u een unieke LUIS-toepassing in elke functiebranche. Eén ontwikkelaar kan gelijktijdig aan meerdere vertakkingen werken, zolang ze overschakelen naar de juiste LUIS-app voor de dev-vertakking waarmee ze momenteel werken.

We raden u aan dezelfde naam te gebruiken voor zowel de functie-vertakking als voor de LUIS-app voor de dev-vertakking die u maakt voor de functiebranche, zodat u minder waarschijnlijk per ongeluk aan de verkeerde app werkt.

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

Meerdere ontwikkelaars kunnen gelijktijdig aan dezelfde vertakking werken

U kunt ondersteuning bieden voor meerdere ontwikkelaars die op hetzelfde moment aan dezelfde functiebranche werken:

  • Ontwikkelaars checken dezelfde functiebranche uit en pushen en pullen wijzigingen die op de gebruikelijke manier door zichzelf en andere ontwikkelaars zijn ingediend terwijl het werk wordt uitgevoerd.

  • Als u het patroon volgt dat hierboven wordt beschreven in Ontwikkelaarskunnen werken vanuit onafhankelijke vertakkingen, gebruikt deze vertakking een unieke LUIS-toepassing ter ondersteuning van ontwikkeling. Die LUIS-app 'dev branch' wordt gemaakt door het eerste lid van het ontwikkelteam dat in de functiebranche aan de slag gaat.

  • Voeg teamleden toe als bijdragers aan de LUIS-app voor dev-vertakking.

  • Wanneer het werk aan de functiebranche is voltooid, exporteert u de actieve versie van de LUIS-app voor de dev-vertakking vanuit de lijst met versies, sla u het bijgewerkte bestand op in de repo en checkt u de wijzigingen in en bekijkt u de .lu .lu wijzigingen.

Wijzigingen van de ene vertakking naar de andere integreren met rebase of merge

Sommige andere ontwikkelaars in uw team die in een andere vertakking werken, hebben mogelijk updates aangebracht in de bron en deze samengevoegd met de main branch nadat u de .lu functie-vertakking hebt gemaakt. Mogelijk wilt u de wijzigingen in uw werkversie opnemen voordat u uw eigen wijzigingen in de functiebranche kunt aanbrengen. U kunt dit doen door opnieuw tebaseren of samen te voegen met main op dezelfde manier als andere code-asset. Omdat de LUIS-app in LUDown-indeling door mensen kan worden gelezen, ondersteunt deze samenvoeging met behulp van standaardhulpprogramma's voor samenvoegen.

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

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

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

  • Vergeet niet dat na het opnieuw maken 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.

Samenvoegings-PRs

Nadat uw pr is goedgekeurd, kunt u uw wijzigingen samenvoegen met uw main branch. Er zijn geen speciale overwegingen van toepassing op de LUDown-bron voor een LUIS-app: deze is door mensen leesbaar en ondersteunt dus samenvoegen met behulp van standaard samenvoegen-hulpprogramma's. Eventuele samenvoegingsconflicten kunnen op dezelfde manier worden opgelost als met andere bronbestanden.

Nadat uw pr is samengevoegd, is het raadzaam om het volgende op te schonen:

  • De vertakking in uw repo verwijderen

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

Net als bij toepassingscode-assets moet u eenheidstests schrijven voor de bijbehorende LUIS-app-updates. U moet continue integratiewerkstromen gebruiken om het volgende te testen:

  • Updates in een pr voordat de pr wordt samengevoegd
  • De main branch LUIS-app nadat een pr is goedgekeurd en de wijzigingen zijn samengevoegd in main.

Zie Testing for DevOps for LUIS (Testen voor DevOps voor LUIS) voor meer informatie over het testen voor LUIS DevOps. Zie Automation workflows for LUIS DevOps (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 pr die geschikt is voor beoordeling. Eenheidstestbestanden worden ook geschreven in LUDown-indeling en kunnen ook eenvoudig worden beoordeeld in een pr.

Versiebeheer

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

Op de LUIS-app main branch moet een versieschema worden toegepast. Wanneer u updates voor een LUIS-app samenvoegt in main, importeert u die bijgewerkte bron in een nieuwe versie in de .lu LUIS-app voor de main branch.

Het is raadzaam om een numeriek versieschema te gebruiken voor de hoofdversie van de LUIS-app, bijvoorbeeld:

major.minor[.build[.revision]]

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

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

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

Nadat u het versienummer voor de meest recente revisie van uw 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 te automatiseren in een CI-werkstroom (Continue integratie).

Zie:

  • Automation-werkstromen voor meer informatie over het implementeren van een CI-werkstroom om een LUIS-app te testen en uit te brengen.
  • Releasebeheer voor informatie over het implementeren van uw LUIS-app.

Versie van de LUIS-app 'feature branch'

Wanneer u werkt met een LUIS-app 'dev branch' die u hebt gemaakt ter ondersteuning van werk in een functievertakking, exporteert u uw app wanneer uw werk is voltooid en neemt u het bijgewerkte in uw pr 'lu op. De vertakking in uw repo en de LUIS-app 'dev branch' moeten worden verwijderd nadat de pr is samengevoegd in main. Omdat deze app alleen bestaat ter ondersteuning van het werk in de functievertakking, hoeft u geen bepaald versieschema toe te passen in deze app.

Wanneer uw wijzigingen in uw pr worden samengevoegd in main, moet op dat moment versien worden toegepast, zodat alle updates naar main onafhankelijk van elkaar worden bijgewerkt.

Volgende stappen