Procedure della metodologia DevOps per LUIS

  • Articolo

Importante

LUIS verrà ritirato il 1 ottobre 2025 e a partire dal 1 aprile 2023 non è più possibile creare nuove risorse LUIS. È consigliabile eseguire la migrazione delle applicazioni LUIS a comprensione del linguaggio conversazionale per beneficiare del supporto continuo del prodotto e delle funzionalità multilingue.

I tecnici software che sviluppano un'app LUIS (Language Understanding) possono applicare procedure DevOps per il controllo del codice sorgente, le compilazioni automatizzate, i test e la 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 lavorare con il codice in collaborazione e di tenere traccia delle modifiche. L'uso di rami consente agli sviluppatori di passare tra versioni diverse della codebase e di lavorare indipendentemente da altri membri del team. Quando gli sviluppatori generano una richiesta pull (PR) per proporre gli aggiornamenti da un ramo a un altro o quando le modifiche vengono unite, ciò potrebbe causare che le compilazioni automatizzate compilino e testino 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 di progettazione software:

  • Controllo del codice sorgente

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

  • Creazione di rami e accorpamento

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

  • Controllo delle versioni

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

  • Revisioni del codice

    • Le modifiche nella richiesta pull vengono presentate come codice sorgente leggibile da esseri umani che può essere revisionato prima di accettare la richiesta pull.

Controllo del codice sorgente

Per mantenere la Definizione dello schema dell'applicazione di un’app LUIS in un sistema di gestione del codice sorgente, usare la rappresentazione dell’app in formato LUDown (.lu). Il formato .lu è preferibile al .json perché leggibile da esseri umani, il che rende più semplice apportare ed esaminare modifiche nelle richieste pull.

Salvare un'app LUIS usando il formato LUDown

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

  • 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 file .lu 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 a LUDown. Usare l'opzione --sort per assicurarsi che le finalità e le espressioni siano ordinate alfabeticamente.
Notare che la funzionalità di esportazione .LU integrata nel portale LUIS ordina già l'output.

Compilare l'app LUIS dall'origine

Per un'app LUIS, la compilazione da origine consiste nel 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 seguenti tipi di file per l'applicazione LUIS devono essere mantenuti sotto il controllo del codice sorgente:

Le credenziali e le chiavi non vengono archiviate

Non includere chiavi o altri valori riservati nei file che si archiviano nel repository, nel quale potrebbero essere visibili a personale non autorizzato. Le chiavi e altri valori di cui è necessario impedire l'archiviazione includono:

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

Strategie per la gestione sicura di segreti

Le strategie per la gestione sicura di segreti includono:

  • Se si usa il controllo della versione Git, è possibile archiviare i segreti di runtime in un file locale e impedirne l'archiviazione aggiungendo un criterio corrispondente al nome del file a un file .gitignore
  • In un flusso di lavoro di automazione, è possibile archiviare i segreti in modo sicuro nella configurazione di parametri offerta da tale tecnologia di automazione. Ad esempio, se si usa GitHub Actions, è possibile archiviare i segreti in modo sicuro in Segreti di GitHub.

Ramificazione e fusione

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

Indipendentemente dalla strategia di diramazione adottata, il principio fondamentale è 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 il lavoro indipendente nei rami con un progetto LUIS:

  • Il ramo principale ha una propria app LUIS. Questa app rappresenta lo stato corrente della soluzione per il progetto, e la sua 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 l’app possa essere distribuita in ambienti di compilazione come Produzione in qualsiasi momento. Quando gli aggiornamenti a .lu vengono uniti in un ramo principale 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 correre il rischio di compromettere il lavoro di altri sviluppatori in altri rami. Questa app "dev branch" è una copia funzionante che deve essere eliminata all’eliminazione del ramo funzionalità.

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 questa procedura:

  1. Creare di un ramo di funzionalità dal ramo principale (a seconda della strategia del ramo, generalmente principale o di sviluppo).

  2. Creare una nuova app LUIS nel portale LUIS (“app dev branch”) esclusivamente al fine di supportare il lavoro nel ramo di funzionalità.

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

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

  3. Usare la versione attiva dell'app del ramo di sviluppo per implementare le modifiche necessarie. È consigliabile lavorare esclusivamente in una singola versione dell'app del ramo di sviluppo per tutte le attività del ramo di funzionalità. Se si crea più di una versione nell'app del ramo di sviluppo, assicurarsi di prendere nota della versione contenente le modifiche da archiviare quando si genera la richiesta pull.

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

  5. Esportare la versione attiva dell'app del ramo di sviluppo come .lu dall'elenco delle versioni.

  6. Archiviare gli aggiornamenti e richiederne il peer review. Se si usa GitHub, si genererà una richiesta pull.

  7. Quando le modifiche vengono approvate, unire gli aggiornamenti nel ramo principale. A questo punto, creare una nuova versione dell'app LUIS principale usando l'aggiornamento .lu nel ramo principale. Per considerazioni sull'impostazione del nome della versione, consultare 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 in più rami contemporaneamente

Se si segue il modello descritto in precedenza in Gli 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 sta lavorando.

È consigliabile usare lo stesso nome sia per il ramo di funzionalità che per l'app LUIS del ramo di sviluppo creata per il lavoro del ramo di funzionalità al fine di evitare il rischio di lavorare inavvertitamente nell'app errata.

Come indicato in precedenza, è consigliabile per praticità lavorare in 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 del ramo di sviluppo a un’altra.

Più sviluppatori possono lavorare contemporaneamente sullo stesso ramo

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

  • Gli sviluppatori eseguono il checkout dello stesso ramo di funzionalità e il push e il pull delle modifiche inviate da loro e da altri sviluppatori mentre il lavoro procede come di consueto.

  • Se si segue il criterio descritto in precedenza in Gli sviluppatori possono 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 .lu dall'elenco delle versioni, salvare il file .lu aggiornato nel repository e archiviare e inviare le richieste pull delle modifiche.

Incorporamento di modifiche da un ramo a un altro con riassegnazione o unione

Altri sviluppatori del team che lavorano in un altro ramo potrebbero aver apportato aggiornamenti all'origine .lu ed averli uniti al ramo principale dopo aver creato il ramo di funzionalità. È consigliabile incorporare tali modifiche nella versione di lavoro prima di continuare ad apportare modifiche personalizzate all'interno del ramo di funzionalità. A tale scopo, è possibile eseguire la riassegnazione o l'unione in un ramo principale come per qualsiasi altro asset di codice. Poiché l'app LUIS in formato LUDown è leggibile da esseri umani, supporta l'unione tramite strumenti di unione standard.

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

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

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

  • Dopo il completamento della riassegnazione o dell’unione, non dimenticare di reimportare l'app nel portale, in modo da lavorare con l'app aggiornata man mano che si continuano ad apportare le proprie modifiche.

Unire richieste pull

Dopo l'approvazione della richiesta pull, è possibile unire le modifiche al ramo principale. Non sono necessarie considerazioni particolari sull’origine LUDown per un'app LUIS: è leggibile da esseri umani e quindi supporta l'unione tramite gli strumenti di unione standard. Eventuali conflitti di unione possono essere risolti allo stesso modo che con 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à.

Come per altri asset di codice dell'applicazione, è necessario scrivere unit test da aggiungere agli aggiornamenti delle app LUIS. È consigliabile usare flussi di lavoro a integrazione continua per testare:

  • Aggiornamenti in una richiesta pull prima che sia effettuata l’unione della richiesta pull
  • L'app LUIS del ramo principale dopo che una richiesta pull è stata approvata e le modifiche sono state unite in un ramo principale.

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

Revisioni del codice

Un'app LUIS in formato LUDown è leggibile da esseri umani, quindi supporta la comunicazione delle modifiche in una richiesta pull adatta alla la revisione. I file di unit test vengono scritti anche in formato LUDown ed è facile effettuarne la revisione in una richiesta pull.

Controllo delle versioni

Un'applicazione è costituita da più componenti che possono includere elementi come un bot in esecuzione nel Servizio di Azure AI Bot, QnA Maker, servizio Voce di Azure AI e altri. Per raggiungere l'obiettivo delle applicazioni accoppiate approssimativamente, 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 o aggiornamenti di rilievo semplicemente esaminando il numero di versione. È più semplice eseguire la versione dell'app LUIS indipendentemente da altri componenti se la si mantiene nel suo 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 nel ramo principale, importare successivamente l'origine aggiornata 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 sull’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, come il supporto per una nuova Finalità o Entità
  • Versione secondaria: modifica secondaria compatibile con le versioni precedenti, ad esempio dopo ulteriore training di portata significativa
  • Compilazione: nessuna modifica delle funzionalità, soltanto una diversa compilazione.

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 nel quale può essere usata in diversi ambienti di compilazione, ad esempio Controllo qualità o Produzione. È consigliabile automatizzare tutti questi passaggi in un flusso di lavoro a integrazione continua (CI).

Vedere:

Controllo delle versioni dell'app “feature branch” di LUIS

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 l'aggiornamento 'lu verrà incluso nella richiesta pull. Il ramo nel repository e l'app LUIS "dev branch" devono essere eliminati dopo l’unione della richiesta pull nel ramo principale. Poiché questa app esiste esclusivamente al fine di supportare il lavoro nel ramo di funzionalità, non è necessario applicare uno schema di controllo delle versioni specifico all'interno dell’app.

Quando le modifiche apportate alla richiesta pull vengono unite in un ramo principale, sarà necessario applicare il controllo delle versioni in modo che tutti gli aggiornamenti al ramo principale vengano sottoposti a controllo delle versioni in modo indipendente.

Passaggi successivi