Procedure della metodologia DevOps per LUIS

  • Articolo

Importante

LUIS verrà ritirato il 1° ottobre 2025 e a partire dal 1° aprile 2023 non sarà possibile creare nuove risorse LUIS. È consigliabile eseguire la migrazione delle applicazioni LUIS alla comprensione del linguaggio conversazionale per trarre vantaggio dal supporto continuo del prodotto e dalle funzionalità multilingue.

I tecnici software che sviluppano un'app Language Understanding (LUIS) possono applicare procedure DevOps relative al controllo del codice sorgente, alle compilazioni automatizzate, ai test e alla gestione delle versioni seguendo queste linee guida.

Strategie di controllo del codice sorgente e gestione rami per LUIS

Uno dei fattori chiave da cui dipende il successo di DevOps è il controllo del codice sorgente. Un sistema di controllo del codice sorgente consente agli sviluppatori di collaborare al codice e di tenere traccia delle modifiche. L'uso dei rami consente agli sviluppatori di passare da versioni diverse della codebase e di lavorare indipendentemente da altri membri del team. Quando gli sviluppatori generano una richiesta pull per proporre gli aggiornamenti da un ramo a un altro o quando le modifiche vengono unite, possono essere il trigger per le compilazioni automatizzate per compilare e testare continuamente il codice.

Usando i concetti e le linee guida descritti in questo documento, è possibile sviluppare un'app LUIS durante il rilevamento delle modifiche in un sistema di controllo del codice sorgente e seguire queste procedure consigliate per la progettazione del software:

  • Controllo del codice sorgente

    • Il codice sorgente per l'app LUIS è in un formato leggibile.
    • Il modello può essere compilato dall'origine in modo ripetibile.
    • Il codice sorgente può essere gestito da un repository di codice sorgente.
    • Le credenziali e i segreti, ad esempio le chiavi, non vengono mai archiviati nel codice sorgente.

  • Diramazione e unione

    • Gli sviluppatori possono lavorare da rami indipendenti.
    • Gli sviluppatori possono lavorare contemporaneamente in più rami.
    • È possibile integrare le modifiche apportate a un'app LUIS da un ramo a un'altra tramite la ribase o l'unione.
    • Gli sviluppatori possono unire una richiesta pull al ramo padre.

  • Versioning

    • Ogni componente in un'applicazione di grandi dimensioni deve essere sottoposto a controllo delle versioni in modo indipendente, consentendo agli sviluppatori di rilevare modifiche di rilievo o aggiornamenti semplicemente esaminando il numero di versione.

  • Revisioni del codice

    • Le modifiche apportate alla richiesta pull vengono presentate come codice sorgente leggibile che può essere esaminato prima di accettare la richiesta pull.

Controllo del codice sorgente

Per mantenere la definizione dello schema dell'app di un'app LUIS in un sistema di gestione del codice sorgente, usare la rappresentazione LUDown (.lu) dell'app. .lu il formato è preferibile formattare .json perché è leggibile, che semplifica l'esecuzione e la revisione delle modifiche nelle richieste pull.

Salvare un'app LUIS usando il formato LUDown

Per salvare un'app LUIS in formato e inserirla nel .lu controllo del codice sorgente:

  • ENTRAMBE: Esportare la versione dell'app come .lu dal portale LUIS e aggiungerla al repository del controllo del codice sorgente

  • OPPURE: usare un editor di testo per creare un .lu file per un'app LUIS e aggiungerlo al repository del controllo del codice sorgente

Suggerimento

Se si usa l'esportazione JSON di un'app LUIS, è possibile convertirla in LUDown. Usare l'opzione --sort per assicurarsi che le finalità e le espressioni siano ordinate in ordine alfabetico.
Si noti che . La funzionalità di esportazione LU integrata nel portale LUIS ordina già l'output.

Compilare l'app LUIS dall'origine

Per un'app LUIS, per compilare dall'origine significa creare una nuova versione dell'app LUIS importando l'origine .lu , per eseguire il training della versione e pubblicarla. È possibile eseguire questa operazione nel portale LUIS o nella riga di comando:

File da mantenere sotto il controllo del codice sorgente

I tipi di file seguenti per l'applicazione LUIS devono essere mantenuti nel controllo del codice sorgente:

Le credenziali e le chiavi non vengono archiviate

Non includere chiavi o valori riservati simili nei file archiviati nel repository in cui potrebbero essere visibili al personale non autorizzato. Le chiavi e altri valori che è necessario impedire l'archiviazione includono:

  • Chiavi di creazione e stima LUIS
  • Endpoint di creazione e stima LUIS
  • Chiavi delle risorse di Azure
  • Token di accesso, ad esempio il token per un'entità servizio di Azure usata per l'autenticazione di automazione

Strategie per la gestione sicura dei segreti

Le strategie per la gestione sicura dei segreti includono:

  • Se si usa il controllo della versione Git, è possibile archiviare i segreti di runtime in un file locale e impedire l'archiviazione del file aggiungendo un criterio per trovare la corrispondenza del nome file a un file con estensione gitignore
  • In un flusso di lavoro di automazione è possibile archiviare i segreti in modo sicuro nella configurazione dei parametri offerta da tale tecnologia di automazione. Ad esempio, se si usa GitHub Actions, è possibile archiviare i segreti in modo sicuro nei segreti di GitHub.

Creazione di rami e merge

I sistemi di controllo della versione distribuiti come Git offrono flessibilità nel modo in cui i membri del team pubblicano, condividono, esaminano ed eselaborano le modifiche del codice tramite rami di sviluppo condivisi con altri utenti. Adottare una strategia di diramazione Git appropriata per il team.

Indipendentemente dalla strategia di diramazione adottata, un principio chiave di tutti è che i membri del team possono lavorare sulla soluzione all'interno di un ramo di funzionalità indipendentemente dal lavoro in corso in altri rami.

Per supportare l'uso indipendente nei rami con un progetto LUIS:

  • Il ramo main ha una propria app LUIS. Questa app rappresenta lo stato corrente della soluzione per il progetto e la versione attiva corrente deve sempre essere mappata all'origine .lu presente nel ramo principale. Tutti gli aggiornamenti all'origine .lu per questa app devono essere esaminati e testati in modo che questa app possa essere distribuita in ambienti di compilazione come Produzione in qualsiasi momento. Quando gli aggiornamenti a .lu vengono uniti in main da un ramo di funzionalità, è necessario creare una nuova versione nell'app LUIS e aggiornare il numero di versione.

  • Ogni ramo di funzionalità deve usare la propria istanza di un'app LUIS. Gli sviluppatori lavorano con questa app in un ramo di funzionalità senza rischi di influire sugli sviluppatori che lavorano in altri rami. Questa app "dev branch" è una copia funzionante che deve essere eliminata quando il ramo di funzionalità viene eliminato.

Ramo di funzionalità Git

Gli sviluppatori possono lavorare da rami indipendenti

Gli sviluppatori possono lavorare sugli aggiornamenti in un'app LUIS indipendentemente da altri rami tramite:

  1. Creazione di un ramo di funzionalità dal ramo principale (a seconda della strategia del ramo, in genere principale o sviluppato).

  2. Creare una nuova app LUIS nel portale LUIS (l'app "dev Branch") esclusivamente per supportare il lavoro nel ramo di funzionalità.

    • Se l'origine per la soluzione esiste già nel ramo, perché è stata salvata dopo il lavoro svolto in un altro ramo precedente nel progetto, creare l'app .lu LUIS del ramo di sviluppo importando il .lu file.

    • Se si inizia a lavorare su un nuovo progetto, non sarà ancora disponibile l'origine per l'app .lu LUIS principale nel repository. Il file verrà creato .lu esportando l'app dev Branch dal portale dopo aver completato il lavoro del ramo di funzionalità e inviarlo come parte della richiesta pull.

  3. Usare la versione attiva dell'app dev Branch per implementare le modifiche necessarie. È consigliabile lavorare solo in una singola versione dell'app dev Branch per tutte le operazioni del ramo di funzionalità. Se si creano più versioni nell'app dev Branch, prestare attenzione a tenere traccia della versione contenente le modifiche da archiviare quando si genera la richiesta pull.

  4. Testare gli aggiornamenti: vedere Test per LUIS DevOps per informazioni dettagliate sul test dell'app del ramo di sviluppo.

  5. Esportare la versione attiva dell'app dev Branch come .ludall'elenco delle versioni.

  6. Archiviare gli aggiornamenti e invitare la revisione peer degli aggiornamenti. Se si usa GitHub, si genererà una richiesta pull.

  7. Quando le modifiche vengono approvate, unire gli aggiornamenti nel ramo main. A questo punto si creerà una nuova versione dell'app LUIS principale , usando l'elemento aggiornato .lu in main. Per considerazioni sull'impostazione del nome della versione, vedere Controllo delle versioni.

  8. Quando il ramo di funzionalità viene eliminato, è consigliabile eliminare l'app LUIS del ramo di sviluppo creata per il lavoro del ramo di funzionalità.

Gli sviluppatori possono lavorare contemporaneamente in più rami

Se si segue il modello descritto in precedenza in Sviluppatori possono lavorare da rami indipendenti, si userà un'applicazione LUIS univoca in ogni ramo di funzionalità. Un singolo sviluppatore può lavorare contemporaneamente su più rami, purché passi all'app LUIS del ramo di sviluppo corretta per il ramo su cui stanno lavorando.

È consigliabile usare lo stesso nome sia per il ramo di funzionalità che per l'app LUIS del ramo di sviluppo creato per il funzionamento del ramo di funzionalità, per renderlo meno probabile che si funzioni accidentalmente nell'app errata.

Come indicato in precedenza, è consigliabile usare una singola versione in ogni app del ramo di sviluppo. Se si usano più versioni, è necessario attivare la versione corretta quando si passa da un'app di dev branch all'altra.

Più sviluppatori possono lavorare contemporaneamente sullo stesso ramo

È possibile supportare più sviluppatori che lavorano contemporaneamente sullo stesso ramo di funzionalità:

  • Gli sviluppatori controllano lo stesso ramo di funzionalità e eseguono il push e il pull delle modifiche inviate da soli e da altri sviluppatori mentre il lavoro continua, come di consueto.

  • Se si segue il modello descritto in Precedenza in Sviluppatori può lavorare da rami indipendenti, questo ramo userà un'applicazione LUIS univoca per supportare lo sviluppo. L'app LUIS "dev branch" verrà creata dal primo membro del team di sviluppo che inizia a lavorare nel ramo delle funzionalità.

  • Aggiungere membri del team come collaboratori all'app LUIS del ramo di sviluppo.

  • Al termine del lavoro del ramo di funzionalità, esportare la versione attiva dell'app LUIS del ramo di sviluppo come .ludall'elenco delle versioni, salvare il file aggiornato .lu nel repository e archiviare e inviare le modifiche.

Incorporamento di modifiche da un ramo a un altro con rebase o merge

Alcuni altri sviluppatori del team che lavorano in un altro ramo potrebbero aver apportato aggiornamenti all'origine .lu e uniti al ramo principale dopo aver creato il ramo di funzionalità. È possibile incorporare le modifiche apportate alla versione di lavoro prima di continuare a apportare modifiche personalizzate all'interno del ramo di funzionalità. A tale scopo, è possibile eseguire il rebase o l'unione in main nello stesso modo di qualsiasi altro asset di codice. Poiché l'app LUIS in formato LUDown è leggibile, supporta l'unione usando strumenti di unione standard.

Se si sta eseguendo ilbasing dell'app LUIS in un ramo di funzionalità, seguire questi suggerimenti:

  • Prima di eseguire la ribase o l'unione, assicurarsi che la copia locale dell'origine per l'app abbia tutte le modifiche più recenti applicate usando il portale LUIS, esportando di nuovo l'app .lu dal portale. In questo modo, è possibile assicurarsi che tutte le modifiche apportate nel portale e non ancora esportate non vadano perse.

  • Durante l'unione, usare gli strumenti standard per risolvere eventuali conflitti di merge.

  • Non dimenticare che dopo la ribase o l'unione è stata completata per riimportare l'app nel portale, in modo da lavorare con l'app aggiornata man mano che si continuano ad applicare le proprie modifiche.

Unione di richieste pull

Dopo l'approvazione della richiesta pull, è possibile unire le modifiche al ramo principale. Nessuna considerazione speciale si applica all'origine LUDown per un'app LUIS: è leggibile e quindi supporta l'unione usando gli strumenti di merge standard. Eventuali conflitti di unione possono essere risolti nello stesso modo di altri file di origine.

Dopo aver unito la richiesta pull, è consigliabile eseguire la pulizia:

  • Eliminare il ramo nel repository

  • Eliminare l'app LUIS "dev branch" creata per il lavoro del ramo di funzionalità.

Analogamente agli asset di codice dell'applicazione, è consigliabile scrivere unit test per accompagnare gli aggiornamenti delle app LUIS. È consigliabile usare flussi di lavoro di integrazione continua per testare:

  • Aggiornamenti in una richiesta pull prima dell'unione della richiesta pull
  • L'app LUIS del ramo principale dopo l'approvazione di una richiesta pull e le modifiche sono state unite in main.

Per altre informazioni sui test per LUIS DevOps, vedere Test per DevOps per LUIS. Per altre informazioni sull'implementazione dei flussi di lavoro, vedere Flussi di lavoro di automazione per LUIS DevOps.

Revisioni del codice

Un'app LUIS in formato LUDown è leggibile, che supporta la comunicazione delle modifiche in una richiesta pull adatta per la revisione. I file di unit test vengono scritti anche in formato LUDown e facilmente verificabili in una richiesta pull.

Controllo delle versioni

Un'applicazione è costituita da più componenti che possono includere elementi come un bot in esecuzione in Azure ai servizio Bot, QnA Maker, servizio Voce di Intelligenza artificiale di Azure e altro ancora. Per raggiungere l'obiettivo delle applicazioni ad accoppiamento libero, usare il controllo della versione in modo che ogni componente di un'applicazione venga sottoposto a controllo delle versioni in modo indipendente, consentendo agli sviluppatori di rilevare modifiche di rilievo o aggiornamenti semplicemente esaminando il numero di versione. È più semplice eseguire la versione dell'app LUIS indipendentemente da altri componenti se la si mantiene nel proprio repository.

L'app LUIS per il ramo principale deve avere uno schema di controllo delle versioni applicato. Quando si uniscono gli aggiornamenti a .lu per un'app LUIS in main, l'origine aggiornata verrà quindi importata in una nuova versione nell'app LUIS per il ramo principale.

È consigliabile usare uno schema di controllo delle versioni numerico per la versione principale dell'app LUIS, ad esempio:

major.minor[.build[.revision]]

Ogni aggiornamento del numero di versione viene incrementato all'ultima cifra.

La versione principale/secondaria può essere usata per indicare l'ambito delle modifiche apportate alla funzionalità dell'app LUIS:

  • Versione principale: modifica significativa, ad esempio il supporto per una nuova finalità o entità
  • Versione secondaria: modifica secondaria compatibile con le versioni precedenti, ad esempio dopo un nuovo training significativo
  • Compilazione: nessuna modifica delle funzionalità, ma solo una compilazione diversa.

Dopo aver determinato il numero di versione per la revisione più recente dell'app LUIS principale, è necessario compilare e testare la nuova versione dell'app e pubblicarla in un endpoint in cui può essere usato in ambienti di compilazione diversi, ad esempio Quality Assurance o Production. È consigliabile automatizzare tutti questi passaggi in un flusso di lavoro di integrazione continua (CI).

Vedere:

Controllo delle versioni dell'app LUIS "Feature Branch"

Quando si usa un'app LUIS "dev branch" creata per supportare il lavoro in un ramo di funzionalità, l'app verrà esportata al termine del lavoro e si includerà l'aggiornamento 'lu nella richiesta pull. Il ramo nel repository e l'app LUIS "dev branch" devono essere eliminati dopo il merge della richiesta pull in main. Poiché questa app esiste esclusivamente per supportare il lavoro nel ramo delle funzionalità, non è necessario applicare uno schema di controllo delle versioni specifico all'interno di questa app.

Quando le modifiche apportate alla richiesta pull vengono unite in main, ovvero quando è necessario applicare il controllo delle versioni, in modo che tutti gli aggiornamenti a main vengano sottoposti a controllo delle versioni indipendentemente.

Passaggi successivi