Informazioni sugli ambienti

Completato

Le pipeline di distribuzione consentono di automatizzare i passaggi nel processo di distribuzione. Spesso è necessario eseguire i passaggi in più ambienti separati. Nell'azienda di giocattoli presso cui l'utente lavora si desidera esaminare le modifiche apportate al codice prima di distribuirle nell'ambiente di produzione.

In questa unità verrà illustrato come gli ambienti in Azure Pipelines consentono di supportare il flusso di lavoro.

Perché sono presenti più ambienti?

I processi di distribuzione apportano modifiche alle risorse di Azure, incluse le risorse in uso. La modifica delle risorse comporta alcuni rischi, perché le modifiche che si distribuiscono potrebbero non comportarsi come previsto. Si potrebbe persino scoprire che le modifiche interrompono la configurazione corrente.

Per ridurre al minimo il rischio di problemi, è consigliabile provare le modifiche in modo sicuro prima di distribuirle nell'ambiente di produzione. Ad esempio, è possibile distribuire le modifiche in un ambiente non di produzione.

Molte organizzazioni configurano più ambienti non di produzione in cui distribuiscono progressivamente le modifiche prima di rilasciarle in produzione. Ogni ambiente non di produzione ha uno scopo specifico e spesso prevede soglie di qualità specifiche che devono essere soddisfatte per procedere all'ambiente successivo. Se si verifica un errore, ad esempio un test non riuscito, la distribuzione si arresta. Man mano che la distribuzione si sposta attraverso ogni ambiente, l'attendibilità delle modifiche aumenta.

Gli ambienti comuni includono:

• Sviluppo: un ambiente di sviluppo viene in genere usato dagli sviluppatori per provare le modifiche apportate e per iterare rapidamente per le proprie attività.

  Gli ambienti di sviluppo prevedono spesso controlli minimi affinché i membri del team possano provare facilmente le idee. È possibile usare un ambiente di sviluppo per testare un'impostazione di configurazione specifica in una risorsa o per vedere come configurare un nuovo sito Web con un database back-end in modo sicuro. Molte di queste modifiche e prove potrebbero non avanzare nel processo di distribuzione, perché si eliminano le idee che non funzionano.

  In alcuni team, è anche possibile configurare un ambiente di sviluppo separato per ogni membro del team affinché non si intralcino l'un l'altro mentre lavorano su nuove funzionalità.

  Gli ambienti di sviluppo sono talvolta chiamati anche ambienti sandbox.

• Test: un ambiente di test è progettato per eseguire test manuali o automatizzati sulle modifiche.

  Gli ambienti di test possono essere usati in un processo di integrazione continua. Dopo aver distribuito una modifica in un ambiente di test, è possibile eseguire test automatizzati sulla modifica. Se tutti i test automatizzati vengono superati, si tratta di una modifica sicura che può essere unita nel ramo principale del progetto. I test automatizzati in genere controllano la funzionalità di base del sistema, unitamente ad altri aspetti, come le violazioni dei criteri nelle risorse appena distribuite.

  È anche possibile creare ambienti di test dedicati per tipi specifici di test, ad esempio test di prestazioni e sicurezza.

• Integrazione: un ambiente di integrazione consente di testare qualsiasi punto di integrazione con altri sistemi.

  In un ambiente di integrazione è possibile simulare transazioni end-to-end. Questi test vengono spesso eseguiti automaticamente, ma molte organizzazioni eseguono anche test manuali su questo ambiente.

  Gli ambienti di integrazione sono talvolta chiamati anche ambienti SIT (System Integration Test).

• Test di accettazione utente: un ambiente di test di accettazione utente (UAT, User Acceptance Test) viene usato per la convalida manuale, in genere da parte degli stakeholder aziendali anziché degli sviluppatori. Nella convalida manuale qualcuno esamina la soluzione e verifica che si comporti come previsto e che soddisfi i requisiti aziendali necessari. Tale persona approva quindi le modifiche affinché la distribuzione possa continuare.

• Pre-produzione: un ambiente di pre-produzione è spesso uno specchio dell'ambiente di produzione, con gli stessi SKU e la stessa configurazione delle risorse. Viene usato come controllo finale per verificare il comportamento della distribuzione di produzione durante e dopo l'applicazione della modifica. Può essere usato anche per verificare se prevedere tempi di inattività durante la distribuzione in produzione.

  Gli ambienti di pre-produzione sono talvolta chiamati anche ambienti di gestione temporanea.

• Produzione: l'ambiente di produzione è quello che useranno gli utenti finali dell'applicazione. Si tratta dell'ambiente live che si vuole proteggere e mantenere il più possibile operativo.

  In alcune organizzazioni potrebbero essere presenti più ambienti di produzione. Ad esempio, potrebbero essere presenti ambienti di produzione in aree geografiche diverse o destinati a gruppi diversi di clienti.

• Demo: il team potrebbe anche creare ambienti dimostrativi (demo) per mostrare l'applicazione agli utenti finali, per il training o per consentire ai team di vendita di mostrare determinate funzionalità ai potenziali clienti. Potrebbero anche essere presenti più ambienti demo per scopi diversi. Un ambiente demo è spesso una replica ridotta dell'ambiente di produzione, con dati dei clienti fittizi.

Ambienti nell'organizzazione

Potrebbero essere presenti varianti di questi ambienti. Alcune organizzazioni usano solo alcuni ambienti e altre ne usano molti di più. Il numero e il tipo di ambienti usati dipendono dalla soluzione distribuita, dalle dimensioni del team che sta creando la soluzione e dall'importanza del carico di lavoro.

In alcuni casi, un singolo ambiente assume il ruolo di molti degli ambienti citati in precedenza. In altri casi potrebbe essere presente una pipeline complessa che viene distribuita in più ambienti, alcuni in parallelo e alcuni in sequenza. Alcune organizzazioni eliminano automaticamente o effettuano il deprovisioning degli ambienti quando non vengono più usati e quindi li ridistribuiscono quando sono necessari in futuro.

Indipendentemente dall'elenco di ambienti scelto dall'organizzazione, l'obiettivo consiste nel migliorare la fiducia in una modifica mentre avanza attraverso la pipeline di distribuzione. Quando una modifica non soddisfa i requisiti di qualità, è necessario poter arrestare la distribuzione di tale modifica in tutti gli ambienti successivi della catena.

Nell'azienda di giocattoli si decide di iniziare con un set di ambienti di base per il sito Web. Oltre all'ambiente di produzione, si creerà un ambiente non di produzione denominato Test:

La pipeline verrà aggiornata per distribuire il codice Bicep nell'ambiente di test ed eseguire alcuni test di base. In caso di esito positivo, si procederà alla distribuzione del codice nell'ambiente di produzione.

Ambienti di pipeline

Anche Azure Pipelines prevede il concetto di ambiente. Si crea un ambiente di Azure Pipelines per rappresentare l'ambiente disponibile in Azure. Quando si definisce la pipeline in un file YAML, i processi di distribuzione vengono collegati a un ambiente specifico. Usando gli ambienti, si ottengono alcune funzionalità aggiuntive nella pipeline.

Controllo e approvazioni

In un ambiente in Azure DevOps è possibile che siano configurati controlli e approvazioni. Ogni volta che l'ambiente viene usato in un processo della pipeline, Azure DevOps verifica che questi controlli e approvazioni abbiano esito positivo prima dell'avvio dell'esecuzione del processo.

Ad esempio, è possibile configurare approvazioni manuali nell'ambiente di produzione. Prima dell'avvio di una distribuzione di produzione, il responsabile approvazione designato riceverà una notifica tramite posta elettronica. Tale persona può verificare manualmente che i criteri e le procedure vengano soddisfatti prima dell'inizio della distribuzione. Ad esempio, il responsabile approvazione potrebbe verificare che tutto funzioni come previsto nell'ambiente di pre-produzione prima di approvare la distribuzione.

È anche possibile eseguire un controllo automatizzato per esaminare i log e le percentuali di errore nell'ambiente di pre-produzione dopo l'ultima distribuzione. Se il controllo conferma che il numero di errori non è aumentato notevolmente, consente alla distribuzione di continuare.

Cronologia di distribuzione

Azure Pipelines tiene traccia della cronologia delle distribuzioni in un ambiente. Questa cronologia offre un modo semplice per tenere traccia di ciò che accade nell'ambiente nel tempo. Consente anche di tracciare una distribuzione rispetto a una richiesta di funzionalità specifica negli elementi di lavoro di Azure Boards o rispetto a un commit nel repository. Questa funzionalità può essere utile se si verifica un problema con una distribuzione ed è necessario identificare la modifica che ha causato il problema.

Sicurezza

È possibile applicare ulteriori controlli di sicurezza agli ambienti. È possibile limitare le pipeline a cui è consentito usare un ambiente specifico. Oppure, impedire a un utente di creare accidentalmente una pipeline secondaria che interagisce con l'ambiente di produzione.

È anche possibile applicare le autorizzazioni dell'utente per controllare gli utenti che possono gestire gli ambienti. Autorizzazioni specifiche possono consentire agli utenti di creare nuovi ambienti, modificare quelli esistenti e visualizzarli insieme alla cronologia delle distribuzioni.

Nota

Quando la pipeline fa riferimento a un ambiente che non esiste ancora, Azure Pipelines lo crea automaticamente. Questa funzionalità può influire sulla sicurezza del progetto Azure DevOps perché si otterranno automaticamente autorizzazioni amministrative per l'ambiente. È consigliabile creare un ambiente in autonomia tramite l'interfaccia Web di Azure DevOps, in modo da avere il controllo completo sulla sicurezza e non ottenere accidentalmente autorizzazioni non necessarie.

Collegare un processo di distribuzione a un ambiente

Nella definizione della pipeline di distribuzione si crea una proprietà deployment per specificare un processo di distribuzione e si specifica il nome dell'ambiente in cui il processo esegue la distribuzione:

- stage: DeployTest
  displayName: Deploy (Test Environment)
  jobs:
  - deployment: DeployWebsite
    environment: Test
    strategy:
      runOnce:
        deploy:
          steps:
            - checkout: self

In questo esempio, il processo denominato DeployWebsite viene collegato all'ambiente Test.

Suggerimento

I processi hanno anche altre proprietà, tra cui la strategia di distribuzione, che non rientrano nell'ambito di questo modulo. Nell'unità di riepilogo sono disponibili collegamenti ad altre informazioni.

Ambienti e connessioni al servizio

Quando si usano più ambienti, è necessario rendere ogni ambiente indipendente dagli altri. Ad esempio, il sito Web dell'ambiente di sviluppo non deve poter accedere a un database all'interno dell'ambiente di produzione.

Lo stesso principio si applica anche alla pipeline di distribuzione. La connessione al servizio usata per la distribuzione nell'ambiente di sviluppo non deve essere in grado di accedere all'ambiente di produzione. Seguendo questo principio si aggiunge un altro livello di protezione per assicurarsi che le distribuzioni non di produzione non influiscano sull'ambiente di produzione.

È necessario creare connessioni al servizio separate per ogni ambiente. Ogni connessione al servizio deve usare la propria entità servizio dedicata, con autorizzazioni specifiche per eseguire la distribuzione solo nella sottoscrizione e nel gruppo di risorse usato da tale ambiente:

Importante

Usare un'entità servizio e una connessione al servizio separate per ogni ambiente in cui si prevede di eseguire la distribuzione. Concedere all'entità servizio le autorizzazioni minime necessarie per la distribuzione nell'ambiente e nessun'altra.

È anche consigliabile separare gli ambienti in Azure. Come minimo, è necessario creare un gruppo di risorse separato per ogni ambiente. In molte situazioni, è meglio creare sottoscrizioni di Azure separate per ogni ambiente. È quindi possibile creare più gruppi di risorse all'interno della sottoscrizione di ogni ambiente.

Applicare assegnazioni di ruolo di Azure affinché gli utenti e le entità servizio possano accedere solo agli ambienti necessari. Prestare attenzione a limitare l'accesso all'ambiente di produzione a un piccolo gruppo di persone e all'entità servizio di distribuzione per tale ambiente.