DevOps-metoder för LUIS

Programvarutekniker som utvecklar en LANGUAGE UNDERSTANDING-app (LUIS) kan tillämpa DevOps-metoder för källkontroll,automatiserade versioner,testning och versionshantering genom att följa dessa riktlinjer.

Källkontroll och förgreningsstrategier för LUIS

En av de viktigaste faktorerna som DevOps lyckas med är källkontrollen. Med ett källkontrollsystem kan utvecklare samarbeta kring kod och spåra ändringar. Med grenar kan utvecklare växla mellan olika versioner av kodbasen och arbeta oberoende av andra medlemmar i teamet. När utvecklare skapar en pull-begäran för att föreslå uppdateringar från en gren till en annan, eller när ändringar slås samman, kan dessa utlösa för automatiserade byggen för att skapa och kontinuerligt testa kod.

Genom att använda de begrepp och riktlinjer som beskrivs i det här dokumentet kan du utveckla en LUIS-app när du spårar ändringar i ett källkontrollsystem och följa dessa metodtips för programvaruteknik:

  • Källkontroll

    • Källkoden för DIN LUIS-app är i ett format som kan läsas av människor.
    • Modellen kan byggas från källan på ett upprepningsbart sätt.
    • Källkoden kan hanteras av en lagringsplats för källkod.
    • Autentiseringsuppgifter och hemligheter som redigering och prenumerationsnycklar lagras aldrig i källkoden.
  • Branchning och sammanslagning

    • Utvecklare kan arbeta från oberoende grenar.
    • Utvecklare kan arbeta i flera grenar samtidigt.
    • Det går att integrera ändringar i en LUIS-app från en gren till en annan via ombaser eller sammanslagning.
    • Utvecklare kan sammanslå en PR till den överordnade grenen.
  • Versionshantering

    • Varje komponent i ett stort program ska versionsdelade oberoende, så att utvecklare kan identifiera större ändringar eller uppdateringar genom att bara titta på versionsnumret.
  • Kodgranskningar

    • Ändringarna i PR presenteras som läsbar källkod för människor som kan granskas innan pr accepteras.

Källkontroll

Om du vill underhålla appschemadefinitionen för en LUIS-app i ett källkodshanteringssystem använder du återgivningen LUDown-format ( .lu ) av appen. .lu formatet är att föredra att formatera eftersom det är läsbart för människor, vilket gör det .json enklare att göra och granska ändringar i PR.

Spara en LUIS-app med formatet LUDown

Så här sparar du en .lu LUIS-app i format och placerar den under källkontroll:

Tips

Om du arbetar med JSON-exporten av en LUIS-app kan du konvertera den till LUDown. Använd alternativet --sort för att se till att avsikter och yttranden sorteras alfabetiskt.
Observera att . FUNKTIONEN FÖR LU-export som är inbyggd i LUIS-portalen sorterar redan utdata.

Skapa LUIS-appen från källan

För en LUIS-app innebär att skapa från källa att skapa en ny LUIS-appversion .lu genom att importera källan , för att träna versionen och publicera den. Du kan göra detta i LUIS-portalen eller på kommandoraden:

Filer som ska underhållas under källkontroll

Följande typer av filer för DITT LUIS-program bör behållas under källkontroll:

Autentiseringsuppgifter och nycklar är inte incheckade

Inkludera inte prenumerationsnycklar eller liknande konfidentiella värden i filer som du checkar in på din lagringsplatsen där de kan vara synliga för obehörig personal. Nycklarna och andra värden som du bör förhindra från att checka in är:

  • LUIS-redigerings- och förutsägelsenycklar
  • LUIS-redigerings- och förutsägelseslutpunkter
  • Azure-prenumerationsnycklar
  • Åtkomsttoken, till exempel token för azure-tjänstens huvudnamn som används för automatiseringsautentisering

Strategier för säker hantering av hemligheter

Strategier för säker hantering av hemligheter är:

  • Om du använder Versionskontroll för Git kan du lagra körningshemligheter i en lokal fil och förhindra incheckning av filen genom att lägga till ett mönster som matchar filnamnet till en .gitignore-fil
  • I ett arbetsflöde för automatisering kan du lagra hemligheter på ett säkert sätt i den parameterkonfiguration som erbjuds av automatiseringstekniken. Om du till exempel använder GitHub åtgärderkan du lagra hemligheter på ett säkert sätt i GitHub hemligheter.

Förgrening och sammanslagning

Distribuerade versionskontrollsystem som Git ger flexibilitet i hur teammedlemmar publicerar, delar, granskar och itererar kodändringar via utvecklingsgrenar som delas med andra. Anta en Git-förgreningsstrategi som passar ditt team.

Oavsett vilken förgreningsstrategi du använder är en viktig princip att teammedlemmar kan arbeta med lösningen inom en funktionsgren oberoende av det arbete som pågår i andra grenar.

Så här stöder du oberoende arbete i grenar med ett LUIS-projekt:

  • Main-grenen har en egen LUIS-app. Den här appen representerar det aktuella tillståndet för din lösning för ditt projekt och dess aktuella aktiva version bör alltid mappa till källan .lu som finns i huvudgrenen. Alla uppdateringar av källan för den här appen bör granskas och testas så att den här appen kan distribueras till att skapa miljöer som .lu produktion när som helst. När uppdateringar av sammanfogas i main från en funktionsgren bör du skapa en ny version i .lu LUIS-appen och göra versionsnumret större.

  • Varje funktionsgren måste använda en egen instans av en LUIS-app. Utvecklare arbetar med den här appen i en funktionsgren utan att det påverkar utvecklare som arbetar i andra grenar. Den här dev-grenappen är en fungerande kopia som ska tas bort när funktionsgrenen tas bort.

Git-funktionsgren

Utvecklare kan arbeta från oberoende grenar

Utvecklare kan arbeta med uppdateringar i en LUIS-app oberoende av andra grenar genom att:

  1. Skapa en funktionsgren från huvudgrenen (beroende på din grenstrategi, vanligtvis huvudsaklig eller utveckla).

  2. Skapa en ny LUIS-app i LUIS-portalen (utvecklingsgrenappen) enbart för att stödja arbetet i funktionsgrenen.

    • Om källan för din lösning redan finns i din -gren, eftersom den sparades efter arbete som utförts i en annan gren tidigare i projektet, skapar du utvecklingsgrenens LUIS-app genom att .lu importera .lu filen.

    • Om du börjar arbeta med ett nytt projekt har du ännu inte källan .lu för din LUIS-huvudapp i lagringsplatsen. Du skapar filen genom att exportera utvecklingsgrenappen från portalen när du har slutfört funktionsgrenen och skicka den som en .lu del av din pr.

  3. Arbeta med den aktiva versionen av utvecklingsgrenappen för att implementera de ändringar som krävs. Vi rekommenderar att du endast arbetar i en enda version av utvecklingsgrenappen för allt funktionsgrensarbete. Om du skapar mer än en version i din dev-grenapp bör du vara noga med att spåra vilken version som innehåller de ändringar som du vill checka in när du skapar din PR.

  4. Testa uppdateringarna – mer information om hur du testar utvecklingsgrenappen finns i Testa för LUIS DevOps.

  5. Exportera den aktiva versionen av dev-grenappen .lu från versionslistan.

  6. Checka in dina uppdateringar och bjud in peer-granskning av dina uppdateringar. Om du använder GitHub du en pull-begäran.

  7. När ändringarna har godkänts sammanslår du uppdateringarna till main-grenen. Nu ska du skapa en ny version av LUIS-huvudappen med hjälp av den uppdaterade .lu huvudversionen. Information om hur du anger versionsnamnet finns i Versionshantering.

  8. När funktionsgrenen tas bort är det en bra idé att ta bort DEV-grenens LUIS-app som du skapade för funktionsgrenens arbete.

Utvecklare kan arbeta i flera grenar samtidigt

Om du följer mönstret som beskrivs ovan i Utvecklarekan arbeta från oberoende grenar använder du ett unikt LUIS-program i varje funktionsgren. En enskild utvecklare kan arbeta med flera grenar samtidigt, så länge de växlar till rätt DEV Branch LUIS-app för den gren som de arbetar med för närvarande.

Vi rekommenderar att du använder samma namn för både funktionsgrenen och luis-appen dev branch som du skapar för funktionsgrenens arbete, så att det blir mindre troligt att du av misstag arbetar med fel app.

Som nämnts ovan rekommenderar vi att du för enkelhetens skull arbetar i en enda version i varje dev branch-app. Om du använder flera versioner är det bra att aktivera rätt version när du växlar mellan dev branch-appar.

Flera utvecklare kan arbeta på samma gren samtidigt

Du kan stödja flera utvecklare som arbetar på samma funktionsgren samtidigt:

  • Utvecklare checkar in samma funktionsgren och push- och pull-ändringar som skickas av sig själva och andra utvecklare medan arbetet fortsätter som vanligt.

  • Om du följer mönstret som beskrivs ovan i Utvecklarekan arbeta från oberoende grenar använder den här grenen ett unikt LUIS-program för utveckling. LUIS-appen "dev branch" skapas av den första medlemmen i utvecklingsteamet som börjar arbeta i funktionsgrenen.

  • Lägg till teammedlemmar som deltagare i DEV-grenens LUIS-app.

  • När funktionsgrenen har slutförts exporterar du den aktiva versionen av DEV-grenens LUIS-app från versionslistan, sparar den uppdaterade filen i lagringsplatsen och checkar in och .lu .lu pr-kontrollerar ändringarna.

Införliva ändringar från en gren till en annan med ombaser eller sammanslagning

Vissa andra utvecklare i ditt team som arbetar i en annan gren kan ha gjort uppdateringar av källan och sammanfogat dem till main-grenen när .lu du har skapat funktionsgrenen. Du kanske vill införliva ändringarna i din arbetsversion innan du fortsätter att göra egna ändringar i funktionsgrenen. Du kan göra detta genom att ombasera eller sammanfoga till main på samma sätt som andra kodtillgånger. Eftersom LUIS-appen i LUDown-format är läsbar för människor stöder den sammanslagning med hjälp av standardsammanslagningsverktyg.

Följ de här tipsen om du återbasera LUIS-appen i en funktionsgren:

  • Innan du återbasar eller sammanfogar kontrollerar du att din lokala kopia av källan för din app innehåller alla dina senaste ändringar som du har tillämpat med hjälp av LUIS-portalen genom att exportera appen igen från .lu portalen först. På så sätt kan du se till att alla ändringar som du har gjort i portalen och som ännu inte har exporterats inte går förlorade.

  • Under sammanslagningen använder du standardverktyg för att lösa eventuella sammanslagningskonflikter.

  • Glöm inte att när ombasen eller sammanslagningen är klar så att du kan importera appen till portalen igen, så att du arbetar med den uppdaterade appen när du fortsätter att tillämpa dina egna ändringar.

Sammanfoga PR:er

När din PR har godkänts kan du sammanslå ändringarna till din main-gren. Inga särskilda överväganden gäller för LUDown-källan för en LUIS-app: den är läsbar för människor och stöder därför sammanslagning med standardverktyg för sammanslagning. Eventuella sammanslagningskonflikter kan lösas på samma sätt som med andra källfiler.

När din PR har sammanfogats rekommenderar vi att du rensar:

  • Ta bort -grenen i din lagringsplatsen

  • Ta bort LUIS-appen "dev branch" som du skapade för funktionsgrenen.

På samma sätt som med programkodtillgångar bör du skriva enhetstester som medföljer LUIS-appuppdateringar. Du bör använda arbetsflöden för kontinuerlig integrering för att testa:

  • Uppdateringar i en PR innan pr sammanfogas
  • Luis-appen för huvudgrenen efter att en pr har godkänts och ändringarna har sammanfogats i main.

Mer information om testning för LUIS DevOps finns i Testing for DevOps for LUIS (Testa för DevOps för LUIS). Mer information om hur du implementerar arbetsflöden finns i Automation-arbetsflöden för LUIS DevOps.

Kodgranskningar

En LUIS-app i LUDown-format är läsbar för människor, som stöder kommunikation av ändringar i en PR som är lämplig för granskning. Enhetstestfiler skrivs också i LUDown-format och kan också enkelt granskas i en PR.

Versionshantering

Ett program består av flera komponenter som kan innehålla sådant som en robot som körs i Azure Bot Service, QnA Maker, Azure Speech Serviceoch mycket mer. För att uppnå målet med löst kopplade program använder du versionskontroll så att varje komponent i ett program versionsdelade oberoende, så att utvecklare kan identifiera större ändringar eller uppdateringar genom att bara titta på versionsnumret. Det är enklare att versions versionera LUIS-appen oberoende av andra komponenter om du underhåller den på en egen lagringsplatsen.

LUIS-appen för main-grenen ska ha ett versionsschema tillämpat. När du sammanfogar uppdateringar till för en LUIS-app till main importerar du sedan den uppdaterade källan till en ny version i .lu LUIS-appen för main-grenen.

Vi rekommenderar att du använder ett schema för numerisk versionshantering för luis-appens huvudversion, till exempel:

major.minor[.build[.revision]]

Varje uppdatering av versionsnumret ökas med den sista siffran.

Huvudversionen/delversionen kan användas för att ange omfånget för ändringarna i LUIS-appens funktioner:

  • Huvudversion: En betydande ändring, till exempel stöd för en ny avsikt eller entitet
  • Delversion: En bakåtkompatibel mindre ändring, till exempel efter betydande ny träning
  • Skapa: Inga funktioner ändras, bara en annan version.

När du har fastställt versionsnumret för den senaste versionen av din luis-huvudapp måste du skapa och testa den nya appversionen och publicera den till en slutpunkt där den kan användas i olika byggmiljöer, till exempel kvalitetskontroll eller produktion. Vi rekommenderar starkt att du automatiserar alla dessa steg i ett ki-arbetsflöde (kontinuerlig integrering).

Se:

Versionshantering av LUIS-appen "funktionsgren"

När du arbetar med en "dev branch"-LUIS-app som du har skapat för att stödja arbete i en funktionsgren exporterar du appen när arbetet är klart och du inkluderar det uppdaterade i din 'lu PR. Grenen i din lagringsplatsen och LUIS-appen "dev branch" bör tas bort när PR har slagits samman till main. Eftersom den här appen enbart finns för att stödja arbetet i funktionsgrenen finns det inget särskilt versionsschema som du behöver tillämpa i den här appen.

När dina ändringar i din pr slås samman till main, det vill säga när versionshanteringen ska tillämpas, så att alla uppdateringar av huvudversionen versionsdelade oberoende av varandra.

Nästa steg