Definire le approvazioni e i controlli

Servizi di Azure DevOps

Una pipeline è costituita da fasi. Un autore della pipeline può controllare se una fase deve essere eseguita definendo le condizioni nella fase. Un altro modo per controllare se e quando una fase deve essere eseguita è tramite approvazioni e controlli.

Le approvazioni e altri controlli non sono definiti nel file yaml. Gli utenti che modificano il file yaml della pipeline non possono modificare i controlli eseguiti prima dell'inizio di una fase. Gli amministratori delle risorse gestiscono i controlli usando l'interfaccia Web di Azure Pipelines.

Le pipeline si basano su risorse come ambienti, connessioni al servizio, pool di agenti, gruppi di variabili e file protetti. I controlli consentono al proprietario della risorsa di controllare se e quando una fase in qualsiasi pipeline può utilizzare una risorsa. In qualità di proprietario di una risorsa, è possibile definire controlli che devono essere soddisfatti prima dell'avvio di una fase che utilizza tale risorsa. Ad esempio, un controllo di approvazione manuale in un ambiente garantisce che la distribuzione in tale ambiente avvenga solo dopo che l'utente designato esamina le modifiche da distribuire.

Una fase può essere costituita da molti processi e ogni processo può utilizzare diverse risorse. Prima che l'esecuzione di una fase possa iniziare, tutti i controlli su tutte le risorse usate in tale fase devono essere soddisfatti. Azure Pipelines sospende l'esecuzione di una pipeline prima di ogni fase e attende il completamento di tutti i controlli in sospeso.

Esistono cinque categorie di approvazioni e controlli e vengono eseguiti nell'ordine in cui sono stati creati all'interno di ogni categoria. I controlli vengono rivalutati in base all'intervallo di ripetizione dei tentativi specificato in ogni controllo. Se tutti i controlli non vengono eseguiti fino al timeout specificato, tale fase non viene eseguita. Se uno dei controlli ha esito negativo (ad esempio, se si rifiuta un'approvazione su una delle risorse), tale fase non viene eseguita.

È possibile riprovare a una fase quando le approvazioni e il timeout dei controlli.

I controlli statici vengono eseguiti per primi e quindi vengono eseguite le approvazioni con controllo preliminare. Le categorie in ordine sono:

1. Controlli statici: controllo ramo, modello obbligatorio e Artefatto di valutazione
2. Verifica preliminare delle approvazioni
3. Controlli dinamici: approvazione, richiamare funzione di Azure, richiamare l'API REST, orario di ufficio, eseguire query sugli avvisi di Monitoraggio di Azure
4. Approvazioni post-verifica
5. Blocco esclusivo

È anche possibile visualizzare l'ordine di esecuzione nella scheda Approvazioni e controlli .

Importante

I controlli possono essere configurati in ambienti, connessioni al servizio, repository, gruppi di variabili, file protetti e pool di agenti.

Le connessioni al servizio non possono essere specificate dalla variabile.

Approvazioni

È possibile controllare manualmente quando una fase deve essere eseguita usando l'approvazione e i controlli. Questo controllo viene comunemente usato per controllare le distribuzioni in ambienti di produzione.

1. Accedere all'organizzazione di Azure DevOps e passare al progetto.

2. Selezionare Ambienti pipeline>e quindi selezionare l'ambiente.

3. Selezionare la scheda Approvazioni e controlli e quindi selezionare il + segno per aggiungere un nuovo controllo.

   

4. Selezionare Approvazioni e quindi avanti.

5. Aggiungere utenti o gruppi come responsabili approvazione designati e, se necessario, fornire istruzioni per i responsabili approvazione. Specificare se si vuole consentire o limitare ai responsabili approvazione di approvare le proprie esecuzioni e specificare il timeout desiderato. Se le approvazioni non vengono completate all'interno del timeout specificato, la fase viene contrassegnata come ignorata.

6. Al termine, fare clic su Crea.

   

7. Dopo l'attivazione del controllo dell'approvazione, viene visualizzata una finestra di richiesta, come illustrato nell'esempio seguente, nell'interfaccia utente. Questa finestra consente ai responsabili approvazione di rifiutare o approvare l'esecuzione, insieme alle istruzioni associate.

   

L'elenco di utenti che possono esaminare un'approvazione è fisso al momento dell'approvazione e dei controlli avvia l'esecuzione. Ovvero, le modifiche apportate all'elenco di utenti e gruppi di un controllo di approvazione eseguite dopo l'avvio dei controlli non vengono prelevate.

Nota

Se un gruppo è designato come responsabile approvazione, per continuare l'esecuzione deve essere approvato un solo utente all'interno del gruppo.

Approvazioni posticipate

Esistono situazioni in cui viene data un'approvazione e l'ora in cui la distribuzione deve iniziare non corrisponde. Ad esempio, potrebbe essere necessario attendere la distribuzione di una nuova versione fino a quando non si verifica un orario di traffico ridotto di sera.

Per risolvere questo scenario, è possibile rinviare un'approvazione e impostare il momento in cui l'approvazione diventa effettiva.

1. Selezionare Rinvia approvazione.

   

2. Impostare l'ora di approvazione.

   

L'approvazione verrà visualizzata nel pannello Controlli come approvazione preliminare. L'approvazione è effettiva al momento impostato.

Controllo ramo

Usando il controllo del ramo, è possibile assicurarsi che tutte le risorse collegate alla pipeline vengano compilate dai rami consentiti e che i rami abbiano la protezione abilitata. Questo controllo consente di controllare la conformità delle versioni e la qualità delle distribuzioni. Nel caso in cui più risorse siano collegate alla pipeline, viene verificata l'origine per tutte le risorse. Se è stata collegata un'altra pipeline, il ramo dell'esecuzione specifica da distribuire viene verificato per la protezione.

Per definire il controllo del controllo del ramo:

1. Nel progetto Azure DevOps passare alla risorsa (ad esempio, ambiente) che deve essere protetta.

2. Passare ad Approvazioni e controlli per la risorsa.

3. Scegliere il controllo Diramazione e specificare un elenco delimitato da virgole di rami consentiti. È possibile imporre che la protezione del ramo sia abilitata. È anche possibile definire il comportamento del controllo se lo stato di protezione per uno dei rami non è noto. Un ramo viene considerato protetto se è stato applicato almeno un criterio (inclusi i criteri applicati a livello di repository).

   

In fase di esecuzione, il controllo convalida i rami per tutte le risorse collegate nell'esecuzione nell'elenco consentito. Se uno dei rami non corrisponde ai criteri, il controllo ha esito negativo e la fase è contrassegnata come non riuscita.

Nota

Il controllo richiede che i nomi dei rami siano completi. Assicurarsi che il formato per il nome del ramo sia refs/heads/<branch name>

ore lavorative

Se si vuole che tutte le distribuzioni nell'ambiente vengano eseguite solo in un intervallo di tempo specifico, il controllo dell'orario di ufficio è la soluzione ideale. Quando si esegue una pipeline, l'esecuzione della fase che usa la risorsa attende l'orario di ufficio. Se sono in esecuzione più esecuzioni contemporaneamente, ognuna di esse viene verificata in modo indipendente. All'inizio dell'orario di ufficio, il controllo viene contrassegnato correttamente per tutte le esecuzioni.

Se l'esecuzione della fase non è iniziata alla fine dell'orario di ufficio (tenuto fino ad un altro controllo), l'approvazione dell'orario di ufficio viene automaticamente ritirata e la rivalutazione è pianificata per il giorno successivo. Il controllo ha esito negativo se l'esecuzione della fase non viene avviata entro il periodo di timeout specificato per il controllo e la fase viene contrassegnata come non riuscita.

Richiamare la funzione di Azure

Le funzioni di Azure sono la piattaforma di calcolo serverless offerta da Azure. Con funzioni di Azure, è possibile eseguire piccole parti di codice (denominate "funzioni") senza preoccuparsi dell'infrastruttura dell'applicazione. Data la flessibilità elevata, le funzioni di Azure offrono un ottimo modo per creare controlli personalizzati. Si include la logica della funzione di Archiviazione di Azure in modo che ogni esecuzione venga attivata nella richiesta HTTP, abbia un breve tempo di esecuzione e restituisca una risposta. Durante la definizione del controllo, è possibile analizzare il corpo della risposta per dedurre se il controllo ha esito positivo. La valutazione può essere ripetuta periodicamente utilizzando l'impostazione Tempo tra valutazioni nelle opzioni di controllo. Altre informazioni

Se il controllo non riesce entro il timeout configurato, la fase associata viene ignorata. Anche le fasi a seconda di esso vengono ignorate. Per altre informazioni, vedere l'attività App per le funzioni di Azure.

Nota

Le variabili della pipeline definite dall'utente sono accessibili al controllo a partire da Sprint 215.

Altre informazioni sul modo consigliato per richiamare i controlli delle funzioni di Azure. I controlli devono seguire regole specifiche a seconda della modalità e del numero di tentativi da rispettare.

Richiama API REST

Richiamare il controllo dell'API REST consente di eseguire l'integrazione con uno dei servizi esistenti. Eseguire periodicamente una chiamata a un'API REST e continuare se restituisce una risposta corretta. Altre informazioni

La valutazione può essere ripetuta periodicamente utilizzando l'impostazione Tempo tra valutazioni nelle opzioni di controllo. Se il controllo non riesce entro il timeout configurato, la fase associata viene ignorata. Anche le fasi a seconda di esso vengono ignorate. Per altre informazioni, vedere Richiamare l'attività API REST.

Nota

Le variabili della pipeline definite dall'utente sono accessibili al controllo a partire da Sprint 215.

Altre informazioni sul modo consigliato per usare i controlli dell'API REST.

Eseguire query sugli avvisi di Monitoraggio di Azure

Monitoraggio di Azure offre visualizzazioni, query, routing, avvisi, scalabilità automatica e automazione sui dati dell'infrastruttura di Azure e ogni singola risorsa di Azure. Gli avvisi sono uno strumento standard per rilevare i problemi relativi all'integrità dell'infrastruttura o dell'applicazione e intraprendere azioni correttive. Le distribuzioni Canary e le implementazioni a fasi sono strategie di distribuzione comuni usate per ridurre il rischio di regressioni alle applicazioni critiche. Dopo la distribuzione in una fase (set di clienti), l'applicazione viene osservata per un periodo di tempo. Integrità dell'applicazione dopo la distribuzione viene usata per decidere se l'aggiornamento deve essere eseguito alla fase successiva o meno.

Eseguire query sugli avvisi di Monitoraggio di Azure consente di osservare Monitoraggio di Azure e assicurarsi che non vengano generati avvisi per l'applicazione dopo una distribuzione. Il controllo ha esito positivo se non vengono attivate regole di avviso al momento della valutazione. Altre informazioni

La valutazione viene ripetuta dopo l'impostazione Tempo tra valutazioni nelle opzioni di controllo. I controlli hanno esito negativo se la fase non ha avviato l'esecuzione entro il periodo di timeout specificato.

Modello obbligatorio

Con il controllo del modello necessario, è possibile applicare le pipeline per l'uso di un modello YAML specifico. Quando questa verifica è presente, una pipeline ha esito negativo se non si estende dal modello a cui si fa riferimento.

Per definire un'approvazione del modello richiesta:

1. Nel progetto Azure DevOps passare alla connessione al servizio che si vuole limitare.

2. Aprire Approvazioni e controlli nel menu accanto a Modifica.

3. Nel menu Aggiungi il primo segno di spunta selezionare Modello obbligatorio.

4. Immettere i dettagli su come accedere al file modello richiesto.

   • Tipo di repository: percorso del repository (GitHub, Azure o Bitbucket).
   • Repository: nome del repository che contiene il modello.
   • Ref: ramo o tag del modello richiesto.
   • Percorso del modello obbligatorio: nome del modello.

È possibile avere più modelli necessari per la stessa connessione al servizio. In questo esempio il modello obbligatorio è production_template.yaml.

Disabilitare un controllo

Quando si esegue il debug di un controllo, potrebbe essere necessario disabilitarlo temporaneamente e quindi abilitarlo di nuovo. Per disabilitare o abilitare un controllo:

1. Nel progetto Azure DevOps passare alla risorsa con un controllo.

2. Aprire la scheda Approvazioni e controlli .

3. Nel menu contestuale selezionare Disabilita o Abilita.

   

Ignorare un controllo

In alcuni casi, ad esempio una distribuzione di hotfix, potrebbe essere necessario ignorare un controllo. È possibile ignorare un controllo solo se si dispone dell'autorizzazione di amministratore per la risorsa in cui è definito il controllo.

Per ignorare un'approvazione, l'orario di ufficio, richiamare la funzione di Azure o richiamare il controllo dell'API REST, selezionare Ignora controllo quando la risorsa è in attesa di revisione. Ecco un esempio di bypass del controllo dell'orario di ufficio.

Quando si ignora un controllo, si noterà chi ha ignorato il controllo nel pannello dei controlli.

Valutare l'artefatto

È possibile valutare gli artefatti da distribuire in un ambiente rispetto ai criteri personalizzati.

Nota

Attualmente funziona solo con gli artefatti dell'immagine del contenitore

Per definire una valutazione dei criteri personalizzata sugli artefatti, seguire questa procedura.

1. Nel progetto di Azure DevOps Services passare all'ambiente che deve essere protetto. Altre informazioni sulla creazione di un ambiente.

   

2. Passare a Approvazioni e verificare la presenza dell'ambiente.

   

3. Selezionare Valuta artefatto.

   

4. Incollare la definizione dei criteri e selezionare Salva. Vedere altre informazioni sulla scrittura di definizioni dei criteri.

   

Quando si esegue una pipeline, l'esecuzione di che viene eseguita viene sospesa prima di entrare in una fase che usa l'ambiente. I criteri specificati vengono valutati rispetto ai metadati dell'immagine disponibili. Il controllo viene superato quando il criterio ha esito positivo e ha esito negativo in caso contrario. La fase è contrassegnata come non riuscita se il controllo ha esito negativo.

Riuscito

È anche possibile visualizzare i log completi dei controlli dei criteri dalla visualizzazione pipeline.

Non riuscito

È anche possibile visualizzare i log completi dei controlli dei criteri dalla visualizzazione pipeline.

Blocco esclusivo

Il controllo di blocco esclusivo consente solo una singola esecuzione dalla pipeline di procedere e può essere impostata a livello di fase o pipeline. Tutte le fasi di tutte le esecuzioni di tale pipeline che usano la risorsa vengono sospese. Al termine della fase che usa il blocco, un'altra fase può continuare a usare la risorsa. Inoltre, è consentita la continuazione di una sola fase.

La lockBehavior proprietà determina il modo in cui le altre fasi gestiscono i blocchi. Quando si specifica la lockBehavior proprietà per una fase, viene creato automaticamente un blocco per tale fase. Esistono due valori possibili lockBehavior :

• runLatest - Solo l'esecuzione più recente acquisisce il blocco alla risorsa. runLatest è l'impostazione predefinita se non è specificato alcun lockBehavior valore.
• sequential - Tutte le esecuzioni acquisiscono il blocco alla risorsa protetta in sequenza.

Per usare un controllo di blocco esclusivo con sequential le distribuzioni o runLatest, seguire questa procedura:

1. Abilitare il controllo di blocco esclusivo nell'ambiente (o in un'altra risorsa protetta). L'opzione di blocco esclusivo è un controllo disponibile.

   

2. Nel file YAML per la pipeline specificare una proprietà denominata lockBehavior. Questa opzione può essere specificata per l'intera pipeline o per una determinata fase:

Impostata su una fase:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Impostare nella pipeline:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Se non si specifica un lockBehavior e un blocco viene impostato su una risorsa, viene usato il valore predefinito di runLatest .

Gestione delle modifiche di ServiceNow

Questo controllo richiede l'installazione dell'estensione ServiceNow Change Management dal marketplace

Il controllo di gestione delle modifiche servicenow consente l'integrazione del processo di gestione delle modifiche di ServiceNow nelle pipeline. Aggiungendo il controllo, è possibile creare automaticamente una nuova richiesta di modifica in ServiceNow all'inizio della fase. La pipeline attende il completamento del processo di modifica prima di avviare la fase. Maggiori dettagli sono disponibili qui.

Più approvazioni e controlli

Una fase può essere costituita da molti processi e ogni processo può utilizzare diverse risorse. Prima che l'esecuzione di una fase possa iniziare, tutti i controlli su tutte le risorse usate in tale fase devono essere soddisfatti. Azure Pipelines sospende l'esecuzione di una pipeline prima di ogni fase e attende il completamento di tutti i controlli in sospeso.

Una singola decisione negativa finale fa sì che la pipeline venga negata e che la fase non riesca. Le decisioni di tutte le approvazioni e i controlli ad eccezione dell'api REST o dell'API REST di Azure e del blocco esclusivo sono finali. È possibile rieseguire correttamente il richiamo dei controlli della funzione o dell'API REST di Azure.

Quando si usa invoke Azure function/REST API check in the recommended way, le decisioni di accesso sono anche finali.

Quando si specifica l'intervallo di tempo tra le valutazioni per un controllo della funzione di Azure o dell'API REST di richiamarlo come diverso da zero, la decisione del controllo non è finale. Questo scenario vale la pena di esplorare.

Esaminiamo un esempio. Si supponga che la pipeline YAML abbia una fase che usa una connessione al servizio. Per questa connessione al servizio sono configurati due controlli:

1. Controllo asincrono, denominato Approvazione esterna concessa, che verifica che venga fornita un'approvazione esterna e sia configurata nel modo consigliato.
2. Controllo sincrono, denominato Motivo distribuzione valido, che verifica che il motivo della distribuzione sia valido e per il quale si imposta l'intervallo di tempo tra le valutazioni su 7 minuti.

Nel diagramma seguente viene illustrata una possibile esecuzione dei controlli.

In questa esecuzione:

• Entrambi i controlli, l'approvazione esterna concessa e il motivo della distribuzione validi, vengono richiamati contemporaneamente. Il motivo di distribuzione Valido ha esito negativo immediatamente, ma poiché l'approvazione esterna concessa è in sospeso, viene ritentata.
• Al minuto 7, viene ritentata la causa della distribuzione valida e questa volta passa.
• Al minuto 15, l'approvazione esterna ha concesso le chiamate ad Azure Pipelines con una decisione corretta. A questo punto, entrambi i controlli vengono superati, quindi la pipeline può continuare a distribuire la fase.

Esaminiamo un altro esempio, con due controlli sincroni. Si supponga che la pipeline YAML abbia una fase che usa una connessione al servizio. Per questa connessione al servizio sono configurati due controlli:

1. Controllo sincrono, denominato Sync Check 1, per il quale è stato impostato l'intervallo di tempo tra le valutazioni su 5 minuti.
2. Controllo sincrono, denominato Sync Check 2, per il quale è stato impostato l'intervallo di tempo tra le valutazioni su 7 minuti.

Nel diagramma seguente viene illustrata una possibile esecuzione dei controlli.

In questa esecuzione:

• Entrambi i controlli, Sync Check 1 e Sync Check 2, vengono richiamati contemporaneamente. Il controllo sincronizzazione 1 viene superato, ma viene ritentato, perché il controllo di sincronizzazione 2 ha esito negativo.
• Al minuto 5, il controllo di sincronizzazione 1 viene ritentato ma ha esito negativo, quindi viene ritentato.
• Al minuto 7, il controllo di sincronizzazione 2 viene ritentato e ha esito positivo. La decisione di passaggio è valida per 7 minuti. Se il controllo di sincronizzazione 1 non supera questo intervallo di tempo, viene ritentato il controllo di sincronizzazione 2 .
• Al minuto 10, il controllo di sincronizzazione 1 viene ritentato ma ha esito negativo, quindi viene ritentato.
• Al minuto 14, il controllo di sincronizzazione 2 viene ritentato e ha esito positivo. La decisione di passaggio è valida per 7 minuti. Se il controllo di sincronizzazione 1 non supera questo intervallo di tempo, viene ritentato il controllo di sincronizzazione 2 .
• Al minuto 15, il controllo di sincronizzazione 1 viene ritentato e ha esito positivo. A questo punto, entrambi i controlli vengono superati, quindi la pipeline può continuare a distribuire la fase.

Esaminiamo un esempio che prevede un'approvazione e un controllo sincrono. Si supponga di configurare un controllo sincrono e di un'approvazione per una connessione al servizio con un intervallo di tempo compreso tra 5 minuti. Fino a quando non viene fornita l'approvazione, il controllo viene eseguito ogni 5 minuti, indipendentemente dalla decisione.

Domande frequenti

I controlli definiti non sono stati avviati. Che cosa è successo?

La valutazione dei controlli inizia una volta soddisfatte le condizioni di fase. È necessario confermare l'esecuzione della fase avviata dopo l'aggiunta dei controlli nella risorsa e che la risorsa viene utilizzata nella fase.

Come è possibile usare i controlli per la pianificazione di una fase?

Usando il controllo orario di ufficio, è possibile controllare l'ora di inizio dell'esecuzione della fase. È possibile ottenere lo stesso comportamento della pianificazione predefinita in una fase nelle versioni della finestra di progettazione.

Come è possibile eseguire in futuro le approvazioni avanzate per una fase pianificata?

Questo scenario può essere abilitato.

1. Il controllo orario di ufficio consente a tutte le fasi di distribuzione in una risorsa di essere pianificata per l'esecuzione tra l'intervallo di tempo
2. Quando le approvazioni vengono configurate nella stessa risorsa, la fase attenderà le approvazioni prima dell'avvio.
3. È possibile configurare entrambi i controlli su una risorsa. La fase attenderà le approvazioni e l'orario di ufficio. Verrà avviato nella finestra pianificata successiva dopo il completamento delle approvazioni.

È possibile attendere il completamento dell'analisi della sicurezza sull'artefatto distribuito?

Per attendere il completamento dell'analisi della sicurezza sull'artefatto distribuito, è necessario usare un servizio di analisi esterno come AquaScan. L'artefatto da distribuire deve essere caricato in una posizione accessibile al servizio di analisi prima dell'avvio dei controlli e può essere identificato usando variabili predefinite. Usando il controllo dell'API REST Invoke, è possibile aggiungere un controllo per attendere l'API nel servizio di sicurezza e passare l'identificatore dell'artefatto come input.

Come è possibile usare le variabili di output delle fasi precedenti in un controllo?

Per impostazione predefinita, solo le variabili predefinite sono disponibili per i controlli. È possibile usare un gruppo di variabili collegate per accedere ad altre variabili. La variabile di output della fase precedente può essere scritta nel gruppo di variabili ed essere accessibile nel controllo.

Altre informazioni

• Richiamare i controlli dell'API REST/funzione di Azure
• Approvazioni e controlli dell'API REST
• API REST delle query di approvazione