Creare un ambiente e sceglierlo come destinazione

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Un ambiente è una raccolta di risorse che è possibile usare come destinazione con le distribuzioni da una pipeline. Esempi tipici di nomi di ambiente sono Dev, Test, QA, Staging e Production. Un ambiente Azure DevOps rappresenta una destinazione logica in cui la pipeline distribuisce il software.

Gli ambienti Azure DevOps non sono disponibili nelle pipeline classiche. Per le pipeline classiche, i gruppi di distribuzione offrono funzionalità simili.

Gli ambienti offrono i vantaggi seguenti.

Vantaggio Descrizione
Cronologia della distribuzione Il nome della pipeline e i dettagli dell'esecuzione vengono registrati per le distribuzioni in un ambiente e nelle relative risorse. Nel contesto di più pipeline destinate allo stesso ambiente o alla stessa risorsa, la cronologia di distribuzione di un ambiente è utile per identificare l'origine delle modifiche.
Tracciabilità dei commit e degli elementi di lavoro Visualizzare i processi all'interno dell'esecuzione della pipeline destinati a un ambiente. È anche possibile visualizzare i commit e gli elementi di lavoro appena distribuiti nell'ambiente. La tracciabilità consente anche di tenere traccia se una modifica del codice (commit) o una funzionalità/correzione di bug (elementi di lavoro) ha raggiunto un ambiente.
Integrità risorse di diagnostica Verificare se l'applicazione funziona allo stato desiderato.
Sicurezza Proteggere gli ambienti specificando quali utenti e pipeline sono autorizzati a definire come destinazione un ambiente.

Mentre un ambiente è un raggruppamento di risorse, le risorse stesse rappresentano le destinazioni di distribuzione effettive. Sono attualmente supportati i tipi di risorse della risorsa Kubernetes e della macchina virtuale.

Quando si crea una pipeline YAML e si fa riferimento a un ambiente che non esiste, Azure Pipelines crea automaticamente l'ambiente quando l'utente che esegue l'operazione è noto e le autorizzazioni possono essere assegnate. Quando Azure Pipelines non dispone di informazioni sull'utente che crea l'ambiente (ad esempio, un aggiornamento YAML da un editor di codice esterno), la pipeline ha esito negativo se l'ambiente non esiste già.

Prerequisiti

Crea un ambiente

  1. Accedere all'organizzazione: https://dev.azure.com/{yourorganization} e selezionare il progetto.

  2. Selezionare Ambienti>pipeline>Crea ambiente.

    Environments

  3. Immettere le informazioni per l'ambiente e quindi selezionare Crea. Le risorse possono essere aggiunte a un ambiente esistente in un secondo momento.

    Screenshot of creating a new environment.

Usare anche una pipeline per creare e distribuire in ambienti. Per altre informazioni, vedere la guida pratica.

Suggerimento

È possibile creare un ambiente vuoto e farvi riferimento dai processi di distribuzione. In questo modo è possibile registrare la cronologia di distribuzione nell'ambiente.

Impostare come destinazione un ambiente da un processo di distribuzione

Un processo di distribuzione è una raccolta di passaggi da eseguire in sequenza. Un processo di distribuzione può essere usato per specificare come destinazione un intero ambiente (gruppo di risorse), come illustrato nel frammento di codice YAML seguente. La pipeline verrà eseguita nel computer myVM perché è specificato il nome della risorsa.

- stage: deploy
  jobs:
  - deployment: DeployWeb
    displayName: deploy Web App
    pool:
      vmImage: 'Ubuntu-latest'
    # creates an environment if it doesn't exist
    environment: 
      name: 'smarthotel-dev'
      resourceName: myVM
      resourceType: virtualMachine
    strategy:
      runOnce:
        deploy:
          steps:
          - script: echo Hello world

Specificare come destinazione una risorsa all'interno di un ambiente dal processo di distribuzione

È possibile definire l'ambito della destinazione della distribuzione in una determinata risorsa all'interno dell'ambiente. È quindi possibile registrare la cronologia di distribuzione in una risorsa specifica all'interno dell'ambiente. I passaggi del processo di distribuzione ereditano automaticamente i dettagli della connessione al servizio dalla risorsa di destinazione del processo di distribuzione.

environment: 
  name: 'smarthotel-dev.bookings'
strategy: 
 runOnce:
   deploy:
     steps:
     - task: KubernetesManifest@0
       displayName: Deploy to Kubernetes cluster
       inputs:
         action: deploy
         namespace: $(k8sNamespace)
         manifests: $(System.ArtifactsDirectory)/manifests/*
         imagePullSecrets: $(imagePullSecret)
         containers: $(containerRegistry)/$(imageRepository):$(tag)
         # value for kubernetesServiceConnection input automatically passed down to task by environment.resource input

Ambiente nei dettagli dell'esecuzione

Tutti gli ambienti destinati ai processi di distribuzione di un'esecuzione specifica di una pipeline sono disponibili nella scheda Ambienti dei dettagli dell'esecuzione della pipeline.

Environments in run details

Se si usa un cluster privato del servizio Azure Kubernetes, la scheda Ambienti non è disponibile.

Approvazioni

Controllare manualmente quando una fase deve essere eseguita usando i controlli di approvazione. Usare i controlli di approvazione per controllare le distribuzioni in ambienti di produzione. I controlli sono disponibili per il proprietario della risorsa per controllare quando una fase in una pipeline utilizza una risorsa. Come proprietario di una risorsa, ad esempio un ambiente, è possibile definire le approvazioni e i controlli che devono essere soddisfatti prima dell'avvio di una fase che utilizza tale risorsa.

Sono supportati controlli di approvazione manuali sugli ambienti. Per altre informazioni, vedere Approvazioni.

Creator, Amministrazione istrator e i ruoli utente possono gestire approvazioni e controlli. Il ruolo Lettore non può gestire le approvazioni e i controlli.

Cronologia di distribuzione

La visualizzazione della cronologia di distribuzione all'interno degli ambienti offre i vantaggi seguenti.

  • Visualizzare i processi da tutte le pipeline destinate a un ambiente specifico. Ad esempio, due microservizi, ognuno con una propria pipeline, viene distribuito nello stesso ambiente. L'elenco della cronologia di distribuzione consente di identificare tutte le pipeline che influiscono su questo ambiente e consente anche di visualizzare la sequenza di distribuzioni da ogni pipeline.

    Screenshot of deployment history listing.

  • Eseguire il drill-down nei dettagli del processo per visualizzare l'elenco dei commit e degli elementi di lavoro distribuiti nell'ambiente. L'elenco dei commit e degli elementi di lavoro è costituito dai nuovi elementi tra le distribuzioni. La prima inserzione include tutti i commit e le voci seguenti includeranno solo le modifiche. Se più commit sono associati alla stessa richiesta pull, verranno visualizzati più risultati negli elementi di lavoro e nelle schede delle modifiche.

    Screenshot of commits under deployment history.

  • Se più elementi di lavoro sono associati alla stessa richiesta pull, nella scheda elementi di lavoro verranno visualizzati più risultati.

    Screenshot of work items under deployment history.

Sicurezza

Autorizzazioni utenti

Controllare chi può creare, visualizzare, usare e gestire gli ambienti con autorizzazioni utente. Esistono quattro ruoli: Creator (ambito: tutti gli ambienti), Lettore, Utente e Amministrazione istrator. Nel pannello autorizzazioni utente dell'ambiente specifico è possibile impostare le autorizzazioni ereditate ed eseguire l'override dei ruoli per ogni ambiente.

  1. Passare all'ambiente specifico da autorizzare.
  2. Selezionare Sicurezza per visualizzare >le impostazioni.
  3. Selezionare Autorizzazioni> utente+Aggiungi>utente o gruppo e quindi selezionare un ruolo appropriato.
Ruolo Descrizione
Creator Ruolo globale, disponibile dall'opzione di sicurezza dell'hub degli ambienti. I membri di questo ruolo possono creare l'ambiente nel progetto. I collaboratori vengono aggiunti come membri per impostazione predefinita. Obbligatorio per attivare una pipeline YAML quando l'ambiente non esiste già.
Lettore I membri di questo ruolo possono visualizzare l'ambiente.
Utente I membri di questo ruolo possono usare l'ambiente durante la creazione o la modifica di pipeline YAML.
Amministratore I membri di questo ruolo possono amministrare le autorizzazioni, creare, gestire, visualizzare e usare gli ambienti. Per un particolare ambiente, il creatore viene aggiunto come Amministrazione inistrator per impostazione predefinita. Amministrazione istrator può anche aprire l'accesso a un ambiente a tutte le pipeline.

Importante

Quando si crea un ambiente, solo l'autore ha il ruolo di amministratore.

Ruolo Descrizione
Creator Ruolo globale, disponibile dall'opzione di sicurezza dell'hub degli ambienti. I membri di questo ruolo possono creare l'ambiente nel progetto. I collaboratori vengono aggiunti come membri per impostazione predefinita. Obbligatorio per attivare una pipeline YAML quando l'ambiente non esiste già.
Lettore I membri di questo ruolo possono visualizzare l'ambiente.
Utente I membri di questo ruolo possono usare l'ambiente durante la creazione o la modifica di pipeline YAML.
Amministratore Oltre a usare l'ambiente, i membri di questo ruolo possono gestire l'appartenenza a tutti gli altri ruoli per l'ambiente. I creatori vengono aggiunti come membri per impostazione predefinita.

Autorizzazioni della pipeline

Usare le autorizzazioni della pipeline per autorizzare tutte le pipeline o selezionate per la distribuzione nell'ambiente.

  • Per rimuovere l'accesso aperto nell'ambiente o nella risorsa, selezionare Limita l'autorizzazione in Autorizzazioni pipeline.
  • Per consentire la distribuzione di pipeline specifiche in un ambiente o in una risorsa specifica, selezionare + e scegliere dall'elenco delle pipeline.

Passaggi successivi

Definire le approvazioni e i controlli

Domande frequenti

D: Perché viene visualizzato un messaggio di errore quando si tenta di creare un ambiente?

R: Se viene visualizzato il messaggio "Accesso negato: {User} necessita di autorizzazioni di creazione per eseguire l'azione", controllare le autorizzazioni a livello di organizzazione. Passare a Impostazioni organizzazione>Utenti e verificare se si ha il ruolo Stakeholder. Il ruolo Stakeholder non può creare ambienti. Modificare il livello di accesso e verificare se è possibile creare ambienti. Per altre informazioni, vedere Domande frequenti sulla gestione delle autorizzazioni e degli utenti.

D: Perché viene visualizzato l'errore "Impossibile trovare XXXX: Ambiente XXXX. L'ambiente non esiste o non è stato autorizzato per l'uso"?

R: Ecco alcuni dei possibili motivi dell'errore:

  • Quando si crea una pipeline YAML e si fa riferimento a un ambiente che non esiste nel file YAML, Azure Pipelines crea automaticamente l'ambiente in alcuni casi:

    • Usare la creazione guidata della pipeline YAML nell'esperienza Web di Azure Pipelines e fare riferimento a un ambiente che non è ancora stato creato.
    • Aggiornare il file YAML usando l'editor Web di Azure Pipelines e salvare la pipeline dopo aver aggiunto un riferimento a un ambiente che non esiste.
  • Nei flussi seguenti Azure Pipelines non contiene informazioni sull'utente che crea l'ambiente: si aggiorna il file YAML usando un altro editor di codice esterno, si aggiunge un riferimento a un ambiente che non esiste e quindi si attiva una pipeline di integrazione manuale o continua. In questo caso, Azure Pipelines non conosce l'utente. In precedenza, questo caso è stato gestito aggiungendo tutti i collaboratori del progetto al ruolo di amministratore dell'ambiente. Qualsiasi membro del progetto potrebbe quindi modificare queste autorizzazioni e impedire ad altri utenti di accedere all'ambiente.

  • È possibile usare le variabili per creare l'ambiente o usare templateContext per passare le proprietà ai modelli. I parametri di runtime non funzioneranno durante la creazione dell'ambiente perché vengono espansi in fase di esecuzione.

  • Un utente con livello di accesso degli stakeholder non può creare l'ambiente perché gli stakeholder non hanno accesso al repository.