Procedure della metodologia DevOps per LUIS

I tecnici software che sviluppano un'app Language Understanding (LUIS) possono applicare DevOps procedure relative al controllo del codice sorgente, alle compilazioniautomatizzate, 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 l'esito positivo 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 di rami consente agli sviluppatori di passare da una versione all'altra della codebase e di lavorare indipendentemente dagli altri membri del team. Quando gli sviluppatori generano una richiesta pull (PR) per proporre aggiornamenti da un ramo a un altro o quando le modifiche vengono unite, queste 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 tenendo traccia 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 dall'utente.
    • 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 la creazione e le chiavi di sottoscrizione, 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 all'altro tramite il rebase o l'unione.
    • Gli sviluppatori possono unire una richiesta pull al ramo padre.
  • Versioning

    • Ogni componente in un'applicazione di grandi dimensioni deve essere con 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 nella richiesta pull vengono presentate come codice sorgente leggibile dall'utente che può essere esaminato prima di accettare la richiesta pull.

Controllo del codice sorgente

Per mantenere la definizione dello schema app di un'app LUIS in un sistema di gestione del codice sorgente, usare la rappresentazione dell'app in formato LUDown ( .lu ). .lu il formato è preferibile per la formattazione perché è leggibile dall'utente, il che rende più semplice apportare ed esaminare .json le modifiche nelle PR.

Salvare un'app LUIS usando il formato LUDown

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

  • ENTRAMBI: Esportare la versione dell'app .lu come 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 utilizza l'esportazione JSON di un'app LUIS, è possibile convertirla in LUDown. Usare --sort l'opzione per assicurarsi che le finalità e le espressioni siano ordinate alfabeticamente.
Si noti che . La funzionalità di esportazione LU incorporata nel portale LUIS ordina già l'output.

Compilare l'app LUIS dall'origine

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

  • Usare il portale LUIS per importare la .lu versione dell'app dal controllo del codice sorgente ed eseguire il training e pubblicare l'app.

  • Usare l'interfaccia della riga di comando di Bot Framework per LUIS nella riga di comando o in un flusso di lavoro CI/CD per importare la versione dell'app dal controllo del codice sorgente in un'applicazione LUIS ed eseguire il training e la pubblicazione dell'app. .lu

File da gestire nel 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 di sottoscrizione o valori riservati simili nei file che si archiviano nel proprio riposino in cui potrebbero essere visibili a personale non autorizzato. Le chiavi e altri valori che è necessario impedire l'archiviazione includono:

  • Chiavi di creazione e stima di LUIS
  • Endpoint di creazione e stima LUIS
  • Chiavi di sottoscrizione 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 di Git, è possibile archiviare i segreti di runtime in un file locale e impedire l'archiviazione del file aggiungendo un modello per la corrispondenza del nome file con 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 ,è possibile archiviare i segreti in modo sicuro GitHub segreti.

Diramazione e unione

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

A seconda della strategia di creazione di rami adottato, un principio chiave di tutti questi è 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 versione attiva corrente deve sempre eseguire il mapping all'origine che si .lu trova nel ramo principale. Tutti gli aggiornamenti all'origine per questa app devono essere esaminati e testati in modo che questa app possa essere distribuita in ambienti di compilazione come .lu produzione in qualsiasi momento. Quando gli aggiornamenti di vengono uniti in main da un ramo di funzionalità, è necessario creare una nuova versione nell'app LUIS e modificare .lu 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 il rischio 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 in modo indipendente da altri rami:

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

  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 eseguito in un altro ramo in precedenza nel progetto, creare l'app LUIS del ramo di sviluppo importando .lu il .lu file.

    • Se si sta iniziando a lavorare su un nuovo progetto, non si avrà ancora l'origine per .lu l'app LUIS principale nel repo. Il file verrà creato esportando l'app dev branch dal portale dopo aver completato il lavoro del ramo di funzionalità e inviarlo come parte della .lu 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 attività del ramo di funzionalità. Se si crea più di una versione nell'app dev Branch, tenere traccia della versione contenente le modifiche da archiviare quando si genera la richiesta pull.

  4. Testare gli aggiornamenti: vedere Testing for LUIS DevOps per informazioni dettagliate sul test dell'app dev Branch.

  5. Esportare la versione attiva dell'app dev Branch come .lu dall'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 principale. A questo punto, si creerà una nuova versione dell'app LUIS principale, usando l'aggiornamento .lu in main. Per considerazioni sull'impostazione del nome della versione, vedere Controllo delle versioni.

  8. Quando il ramo di funzionalità viene eliminato, è buona idea 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 Glisviluppatori possono lavorare da rami indipendenti, si userà un'applicazione LUIS univoca in ogni ramo di funzionalità. Un singolo sviluppatore può lavorare su più rami contemporaneamente, purché si passa all'app LUIS del ramo di sviluppo corretto per il ramo su cui sta attualmente 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à, per rendere meno probabile che si usi accidentalmente l'app errata.

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

Più sviluppatori possono lavorare contemporaneamente nello stesso ramo

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

  • Gli sviluppatori controllano lo stesso ramo di funzionalità e estrarranno ed estrarranno le modifiche inviate da se stessi e da altri sviluppatori durante il lavoro, come di consueto.

  • Se si segue il modello descritto in precedenza in Glisviluppatori 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 di funzionalità.

  • Aggiungere i membri del team come collaboratori all'app LUIS di Dev Branch.

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

Incorporamento di modifiche da un ramo a un altro con il rebase o l'unione

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

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

  • Prima di eseguire il rebase 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 .lu l'app dal portale. In questo modo, è possibile assicurarsi che tutte le modifiche apportate nel portale e non ancora esportate non andranno perse.

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

  • Non dimenticare che il rebase o l'unione sono stati completati per reimportare l'app nel portale, in modo da lavorare con l'app aggiornata mentre si continuano ad applicare le proprie modifiche.

Unire le RS

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

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

  • Eliminare il ramo nel repo

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

Come per gli asset del 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 del merge della richiesta pull
  • L'app LUIS del ramo principale dopo l'approvazione di una richiesta pull e il merge delle modifiche in main.

Per altre informazioni sui test per LUIS DevOps, vedere Testing for DevOps for 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 dall'utente, che supporta la comunicazione delle modifiche in una richiesta pull adatta per la revisione. I file di unit test sono anche scritti in formato LUDown e facilmente recensibili in una richiesta pull.

Controllo delle versioni

Un'applicazione è costituita da più componenti che possono includere elementi quali un bot inesecuzione in servizio Azure Bot, QnA Maker,servizio Voce di Azuree altro ancora. Per raggiungere l'obiettivo delle applicazioni ad accoppiato libero, usare il controllo della versione in modo che ogni componente di un'applicazione sia con 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 in modo indipendente da altri componenti se viene mantenuta nel proprio repo.

All'app LUIS per il ramo principale deve essere applicato uno schema di controllo delle versioni. Quando si uniscono gli aggiornamenti di per un'app LUIS in main, si importerà quindi l'origine aggiornata in una nuova versione .lu 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 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 di 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 usata in ambienti di compilazione diversi, ad esempio Quality Assurance o Production. È consigliabile automatizzare tutti questi passaggi in un flusso di lavoro di integrazione continua.

Vedere:

  • Flussi di lavoro di automazione per informazioni dettagliate su come implementare un flusso di lavoro ci per testare e rilasciare un'app LUIS.
  • Release Management informazioni su come distribuire l'app LUIS.

Controllo delle versioni dell'app LUIS 'feature branch'

Quando si lavora con un'app LUIS "dev branch" creata per supportare il lavoro in un ramo di funzionalità, l'app verrà esportata al termine del lavoro e verrà incluso l'aggiornamento nella richiesta 'lu pull. Il ramo nel repo 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 di funzionalità, non è necessario applicare uno schema di controllo delle versioni specifico all'interno di questa app.

Quando le modifiche nella richiesta pull vengono unite in main, cio' quando il controllo delle versioni deve essere applicato, in modo che tutti gli aggiornamenti a main siano con controllo delle versioni in modo indipendente.

Passaggi successivi