Testare e distribuire il modello convertito

Completato

Dopo aver migliorato il file Bicep durante la fase di refactoring, è necessario testare e distribuire il file nell'ambiente di Azure. La quarta e la quinta fase del flusso di lavoro consigliato sono la fase di test e la fase di distribuzione:

Diagram that shows the test and deploy phases of the recommended workflow for migrating Azure resources to Bicep.

L'obiettivo principale di queste due fasi è testare il file Bicep usando gli strumenti disponibili e quindi distribuire il file nell'ambiente di Azure.

Fase di test

Gli obiettivi della fase di test della migrazione delle risorse a Bicep consiste nel verificare l'integrità dei modelli migrati ed eseguire una distribuzione di prova.

La fase di test è costituita da due passaggi da completare in questo ordine:

  1. Eseguire l'operazione di simulazione della distribuzione del modello di ARM.
  2. Eseguire una distribuzione di prova.

Diagram that shows a Bicep file being tested and deployed to Azure.

L'operazione di simulazione fornisce un'anteprima delle modifiche che verranno apportate quando si distribuisce il file Bicep. Usare una distribuzione di test per confrontare le differenze tra le risorse originali e le risorse appena distribuite.

Che cos'è l'operazione di simulazione per la distribuzione di modelli di ARM?

Quando si distribuiscono nuove risorse o si modificano le risorse esistenti, è possibile introdurre modifiche che causano interruzioni negli ambienti. La distribuzione potrebbe modificare o eliminare risorse esistenti, creare nuove risorse configurate in modo non corretto o influire sulle funzionalità complessive dell'applicazione.

L’operazione di simulazione della distribuzione del modello di ARM può semplificare la verifica dei modelli convertiti prima della distribuzione. Questa operazione confronta lo stato corrente dell'ambiente con lo stato previsto definito nel modello. Lo strumento restituisce l'elenco delle modifiche che si verificheranno senza applicare le modifiche all'ambiente. Questo processo può aumentare il livello di attendibilità nelle distribuzioni. È possibile usare l'operazione di simulazione con distribuzioni sia in modalità incrementale che completa. Anche se si prevede di distribuire il modello usando la modalità incrementale, è consigliabile eseguire l'operazione di simulazione in modalità completa. L'esecuzione dell'operazione di simulazione consente di identificare le risorse che potrebbero essere state accidentalmente lasciate fuori dal modello.

Nota

L'operazione di simulazione potrebbe elencare alcune proprietà delle risorse come eliminate, quando in realtà non cambiano. Questi risultati sono considerati rumore.

Distribuzione di prova

Prima di introdurre il modello Bicep convertito nell'ambiente di produzione, è consigliabile eseguire più distribuzioni di prova. In presenza di più ambienti (produzione, sviluppo, test), è possibile provare prima di tutto a distribuire il modello in uno degli ambienti non di produzione. Dopo la distribuzione, confrontare le risorse originali per verificarne la coerenza con le nuove distribuzioni di risorse.

Suggerimento

Se non si ha accesso a un ambiente non di produzione per testare la distribuzione, distribuire il modello Bicep in un nuovo ambiente.

Fase di distribuzione

L’obiettivo della fase di distribuzione della migrazione delle risorse a Bicep consiste nel distribuire il file Bicep finale nell'ambiente di produzione. Prima della distribuzione in produzione, è consigliabile prendere in considerazione alcuni aspetti.

La fase di distribuzione è costituita da quattro passaggi, completati in questo ordine:

  1. Preparare un piano di ripristino dello stato precedente.
  2. Eseguire l'operazione di simulazione nell'ambiente di produzione.
  3. Distribuire manualmente il file Bicep.
  4. Eseguire smoke test.

Questi passaggi consentono di prepararsi per eventuali problemi relativi alle distribuzioni di produzione.

Diagram that shows a Bicep file being deployed to Azure.

Preparare un piano di ripristino dello stato precedente

La possibilità di eseguire il ripristino da una distribuzione non riuscita è fondamentale. Dedicare tempo allo sviluppo di un piano di ripristino dello stato precedente da adottare se vengono introdotte modifiche che causano interruzioni negli ambienti. Il piano deve tenere conto della strategia di continuità aziendale e ripristino di emergenza (BCDR) dell'organizzazione. Eseguire l'inventario dei tipi di risorse distribuite, ad esempio macchine virtuali, app Web e database. È anche consigliabile prendere in considerazione il piano dati di ogni risorsa. È previsto un modo per ripristinare una macchina virtuale e i relativi dati? È disponibile una strategia per ripristinare un database dopo l'eliminazione o per recuperare dati da un account di archiviazione? Un piano di ripristino dello stato precedente ben congegnato consente di ridurre al minimo i tempi di inattività in caso di problemi derivanti da una distribuzione.

Eseguire l'operazione di simulazione sull'ambiente di produzione

L'operazione di simulazione è già stata eseguita in altri ambienti per verificare che il nuovo file Bicep non introduca modifiche che causano interruzioni. Prima di distribuire il file Bicep finale in produzione, eseguire l'operazione di simulazione nell'ambiente di produzione. Assicurarsi di usare i valori dei parametri di produzione e prendere in considerazione la documentazione dei risultati.

Eseguire la distribuzione manualmente

Se si prevede di usare il modello convertito in una pipeline, ad esempio Azure DevOps o GitHub Actions, è consigliabile eseguire la distribuzione prima dal computer locale. È meglio verificare la funzionalità del modello prima di aggiungerlo alla pipeline di produzione. Dopo aver visto come funziona il modello, è possibile rispondere rapidamente se si verifica un problema.

Eseguire smoke test

Al termine della distribuzione, è consigliabile eseguire una serie di smoke test. Uno smoke test è un semplice controllo che verifica le funzioni dell'applicazione o del carico di lavoro. Eseguire ad esempio test per verificare se l'app Web è accessibile tramite i normali canali di accesso, tra cui la rete Internet pubblica o attraverso una VPN aziendale. Per i database, provare a stabilire una connessione di database ed eseguire una serie di query. Con le macchine virtuali, accedere alla macchina virtuale e assicurarsi che tutti i servizi siano in esecuzione.