Definire la pipeline classica
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Azure Pipelines offre una pipeline altamente configurabile e gestibile per le versioni in più fasi, ad esempio sviluppo, gestione temporanea, controllo di qualità e produzione. offre anche l'opportunità di implementare controlli e approvazioni in ogni fase specifica.
In questa esercitazione si approfondiranno i seguenti argomenti:
- Trigger di distribuzione continua
- Aggiunta di fasi
- Aggiunta di approvazioni di pre-distribuzione
- Creazione di versioni e distribuzioni di monitoraggio
Prerequisiti
Saranno necessari gli elementi seguenti:
Pipeline di versione che contiene almeno una fase. Se non è già disponibile, è possibile crearlo seguendo una delle guide introduttive e le esercitazioni seguenti:
Due destinazioni separate in cui si distribuirà l'app. Possono trattarsi di macchine virtuali, server Web, gruppi di distribuzione fisici locali o altri tipi di destinazione della distribuzione. In questo esempio vengono usati app Azure istanze del sito Web del servizio. Se si decide di eseguire la stessa operazione, sarà necessario scegliere nomi univoci, ma è consigliabile includere "QA" nel nome di uno e "Produzione" nel nome dell'altro in modo da poterli identificare facilmente. Usare il portale di Azure per creare una nuova app Web.
Trigger di distribuzione continua (CD)
L'abilitazione del trigger di distribuzione continua indicherà alla pipeline di creare automaticamente una nuova versione ogni volta che è disponibile una nuova compilazione.
In Azure Pipelines aprire la scheda Versioni . Selezionare la pipeline di versione selezionare Modifica.
Selezionare l'icona trigger distribuzione continua nella sezione Artefatti per aprire il pannello del trigger. Assicurarsi che questa opzione sia abilitata in modo che venga creata una nuova versione dopo il completamento di ogni nuova compilazione completata.
Selezionare l'icona Condizioni di pre-distribuzione nella sezione Fasi per aprire il pannello condizioni. Assicurarsi che il trigger per la distribuzione in questa fase sia impostato su Dopo il rilascio. Ciò significa che una distribuzione verrà avviata automaticamente quando viene creata una nuova versione da questa pipeline di versione.
È anche possibile configurare trigger di rilascio, trigger di fase o pianificare distribuzioni.
Aggiungere fasi
In questa sezione verranno aggiunte due nuove fasi alla pipeline di versione: qa e produzione (due siti Web di servizi app Azure in questo esempio). Si tratta di uno scenario tipico in cui si distribuisce inizialmente in un server di test o staging e quindi in un server live o di produzione. Ogni fase rappresenta una destinazione di distribuzione.
Selezionare la scheda Pipeline nella pipeline di versione e selezionare la fase esistente. Modificare il nome della fase in Produzione.
Selezionare l'elenco a discesa + Aggiungi e scegliere Clona fase (l'opzione clone è disponibile solo quando è selezionata una fase esistente).
In genere, si vogliono usare gli stessi metodi di distribuzione con un test e una fase di produzione, in modo che sia possibile assicurarsi che le app distribuite si comportino allo stesso modo. La clonazione di una fase esistente è un buon modo per assicurarsi di avere le stesse impostazioni per entrambi. È quindi sufficiente modificare le destinazioni di distribuzione.
La fase clonata avrà il nome Copia di produzione. Selezionarlo e modificare il nome in QA.
Per riorganizzare le fasi nella pipeline, selezionare l'icona Condizioni di pre-distribuzione nella fase di controllo di qualità e impostare il trigger su Dopo il rilascio. Il diagramma della pipeline mostrerà quindi le due fasi in parallelo.
Selezionare l'icona Condizioni di pre-distribuzione nella fase di produzione e impostare il trigger su Dopo la fase, quindi selezionare QA nell'elenco a discesa Fasi . Il diagramma della pipeline indicherà ora che le due fasi verranno eseguite nell'ordine corretto.
Nota
È possibile configurare la distribuzione per l'avvio quando una distribuzione nella fase precedente ha esito positivo parzialmente . Ciò significa che la distribuzione continuerà anche se un'attività specifica non critica non è riuscita. Questa operazione viene in genere usata in distribuzioni di fork e join che vengono distribuite in diverse fasi in parallelo.
Selezionare l'elenco a discesa Attività e selezionare la fase qa .
A seconda delle attività in uso, modificare le impostazioni in modo che questa fase venga distribuita nella destinazione "QA". Nell'esempio verrà usata l'attività Deploy app Azure Service come illustrato di seguito.
Aggiungere approvazioni di pre-distribuzione
La pipeline di versione modificata in precedenza viene distribuita in qa e produzione. Se la distribuzione al controllo di qualità ha esito negativo, la distribuzione nell'ambiente di produzione non verrà attivata. È consigliabile verificare sempre se l'app funziona correttamente nella fase di controllo di qualità o test prima della distribuzione nell'ambiente di produzione. L'aggiunta di approvazioni garantisce che tutti i criteri vengano soddisfatti prima della distribuzione nella fase successiva. Per aggiungere approvazioni alla pipeline, seguire questa procedura:
Selezionare la scheda Pipeline , l'icona Condizioni di pre-distribuzione e i responsabili approvazione pre-distribuzione.
Nella casella di testo Responsabili approvazione immettere gli utenti che saranno responsabili dell'approvazione della distribuzione. È anche consigliabile deselezionare la casella di controllo L'utente che richiede una versione o una distribuzione non deve approvarlo .
È possibile aggiungere tutti i responsabili approvazione necessari, sia singoli utenti che gruppi di organizzazioni. È anche possibile configurare le approvazioni post-distribuzione selezionando l'icona "utente" sul lato destro della fase nel diagramma della pipeline. Per altre informazioni, vedere Rilascia controlli e approvazioni.
Seleziona Salva.
Creare una versione
Ora che l'installazione della pipeline di versione è stata completata, è possibile avviare la distribuzione. A tale scopo, verrà creata manualmente una nuova versione. In genere, una versione viene creata automaticamente quando è disponibile un nuovo artefatto di compilazione. Tuttavia, in questo scenario verrà creato manualmente.
Selezionare l'elenco a discesa Versione e scegliere Crea versione.
Immettere una descrizione per la versione, verificare che siano selezionati gli artefatti corretti e quindi selezionare Crea.
Verrà visualizzato un banner che indica che è stata creata una nuova versione. Selezionare il collegamento versione per visualizzare altri dettagli.
La pagina di riepilogo della versione mostrerà lo stato della distribuzione in ogni fase.
Altre visualizzazioni, ad esempio l'elenco delle versioni, visualizzano anche un'icona che indica che l'approvazione è in sospeso. L'icona mostra un popup contenente il nome della fase e altri dettagli quando si punta a esso. In questo modo, un amministratore può vedere quali versioni sono in attesa di approvazione, nonché l'avanzamento complessivo di tutte le versioni.
Selezionare l'icona pending_approval per aprire il pannello della finestra di approvazione. Immettere un breve commento e selezionare Approva.
Nota
È possibile pianificare la distribuzione in un secondo momento, ad esempio durante le ore non di punta. È anche possibile riassegnare l'approvazione a un utente diverso. Gli amministratori del rilascio possono accedere ed eseguire l'override di tutte le decisioni di approvazione.
Monitorare le distribuzioni
I log di distribuzione consentono di monitorare ed eseguire il debug della versione dell'applicazione. Per controllare i log della distribuzione, seguire questa procedura:
Nel riepilogo della versione passare il puntatore del mouse su una fase e selezionare Log.
Durante la distribuzione, è comunque possibile accedere alla pagina dei log per visualizzare i log in tempo reale di ogni attività.
Selezionare un'attività per visualizzare i log per l'attività specifica. In questo modo è più semplice tracciare ed eseguire il debug dei problemi di distribuzione. È anche possibile scaricare singoli log attività o un file ZIP di tutti i file di log.
Se sono necessarie informazioni aggiuntive per eseguire il debug della distribuzione, è possibile eseguire la versione in modalità di debug.
Passaggio successivo
Commenti e suggerimenti
Presto disponibile: nel corso del 2024 verranno dismessi i problemi di GitHub come meccanismo di feedback per il contenuto e verranno sostituiti con un nuovo sistema di feedback. Per altre informazioni, vedere: https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per