Pipeline di versione classica

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Le pipeline di versione classica offrono agli sviluppatori un framework per la distribuzione di applicazioni in più ambienti in modo efficiente e sicuro. Usando le pipeline di versione classiche, è possibile automatizzare i processi di test e distribuzione, configurare strategie di distribuzione flessibili, incorporare flussi di lavoro di approvazione e garantire transizioni di applicazioni uniformi tra varie fasi.

Come funzionano le pipeline di versione

Come parte di ogni distribuzione, Azure Pipelines esegue i passaggi seguenti:

  1. Approvazione pre-distribuzione:

    Quando viene attivata una nuova richiesta di distribuzione, Azure Pipelines verifica se è necessaria un'approvazione di pre-distribuzione prima di distribuire una versione in una fase. Se è necessaria l'approvazione, invia notifiche tramite posta elettronica ai responsabili approvazione pertinenti.

  2. Processo di distribuzione della coda:

    Azure Pipelines pianifica il processo di distribuzione in un agente disponibile.

  3. Selezione agente:

    Un agente disponibile preleva il processo di distribuzione. Una pipeline di versione può essere configurata per selezionare dinamicamente un agente appropriato durante il runtime.

  4. Scaricare gli artefatti:

    L'agente recupera e scarica tutti gli artefatti specificati nella versione.

  5. Eseguire le attività di distribuzione:

    L'agente esegue tutte le attività nel processo di distribuzione.

  6. Generare i log di stato:

    L'agente genera log completi per ogni passaggio di distribuzione e li invia ad Azure Pipelines.

  7. Approvazione post-distribuzione:

    Al termine della distribuzione in una fase, Azure Pipelines verifica se è necessaria un'approvazione post-distribuzione per tale fase specifica. Se non è necessaria alcuna approvazione o una volta ottenuta un'approvazione necessaria, procede con l'avvio della distribuzione alla fase successiva.

Screenshot che mostra i passaggi di distribuzione in Azure Pipelines.

Modello di distribuzione

Le pipeline di versione di Azure supportano un'ampia gamma di origini degli artefatti, tra cui Jenkins, Azure Artifacts e Team City. L'esempio seguente illustra un modello di distribuzione usando le pipeline di versione di Azure:

Nell'esempio seguente la pipeline è costituita da due artefatti di compilazione provenienti da pipeline di compilazione separate. L'applicazione viene inizialmente distribuita nella fase di sviluppo e quindi in due fasi di controllo di qualità separate. Se la distribuzione ha esito positivo in entrambe le fasi di controllo di qualità, l'applicazione verrà distribuita nell'anello Prod 1 e quindi nell'anello Prod 2. Ogni anello di produzione rappresenta più istanze della stessa app Web, distribuite in posizioni diverse in tutto il mondo.

Screenshot che mostra una procedura di distribuzione della pipeline di versione.

Domande frequenti

D: Come è possibile modificare le variabili in fase di rilascio?

R: Nella scheda Variabili della pipeline di versione selezionare la casella di controllo Imposta tabella in fase di rilascio per le variabili che si desidera modificare quando viene accodata una versione.

Screenshot che mostra come abilitare la funzionalità impostabile in fase di rilascio.

Successivamente, quando si genera una nuova versione, è possibile modificare i valori di tali variabili.

Screenshot che mostra come modificare le variabili in fase di rilascio.

D: Quando sarebbe più appropriato modificare una versione anziché la pipeline che la definisce?

R: È possibile modificare le approvazioni, le attività e le variabili di un'istanza di versione. Tuttavia, queste modifiche verranno applicate solo a tale istanza. Se si vuole applicare le modifiche a tutte le versioni future, modificare invece la pipeline di versione.

D: Quali sono gli scenari in cui è utile la funzionalità "abbandonare una versione"?

R: Se non si prevede di riutilizzare la versione o si vuole impedirne l'uso, è possibile abbandonare la versione come indicato di seguito Pipeline (...) >>Abbandonare. Non è possibile abbandonare una versione quando è in corso una distribuzione, è prima necessario annullare la distribuzione.

Screenshot che mostra come abbandonare una versione.

D: Ricerca per categorie gestire la denominazione delle nuove versioni?

R: La convenzione di denominazione predefinita per le pipeline di versione è la numerazione sequenziale, in cui le versioni sono denominate Release-1, Release-2 e così via. Tuttavia, è possibile personalizzare lo schema di denominazione modificando la maschera di formato del nome della versione. Nella scheda Opzioni della pipeline di versione passare alla pagina Generale e modificare la proprietà Formato nome versione in base alle proprie preferenze.

Quando si specifica la maschera di formato, è possibile usare le variabili predefinite seguenti. Esempio: il formato del nome della versione seguente: Release $(Rev:rrr) per build $(Build.BuildNumber) $(Build.DefinitionName) creerà la versione seguente: Release 002 per build 20170213.2 MySampleAppBuild.

Variabile Descrizione
Rev: rr Numero autoincremented con almeno il numero specificato di cifre.
Data/Data: MMddyy Data corrente, con il formato predefinito MMddyy. Sono supportate tutte le combinazioni di M/MMM/MMMM, d/ddd/ddd/ggdd, y/a/a, h/hh/HH, m/mm, s/ss.
System.TeamProject Nome del progetto a cui appartiene la compilazione.
Release.ReleaseId ID della versione, univoco in tutte le versioni del progetto.
Release.DefinitionName Nome della pipeline di versione a cui appartiene la versione corrente.
Build.BuildNumber Numero della build contenuta nella versione. Se una versione include più build, è il numero della build primaria.
Build.DefinitionName Nome della pipeline della compilazione contenuta nella versione. Se una versione include più build, è il nome della pipeline della compilazione primaria.
Artifact.ArtifactType Tipo dell'origine dell'artefatto collegato alla versione. Ad esempio, può trattarsi di Azure Pipelines o Jenkins.
Build.SourceBranch Ramo dell'origine dell'artefatto primario. Per Git, si tratta del formato principale se il ramo è refs/heads/main. Per controllo della versione di Team Foundation, si tratta del ramo modulo se il percorso del server radice per l'area di lavoro è $/teamproject/branch. Questa variabile non è impostata per Jenkins o altre origini di artefatti.
Variabile personalizzata Valore di una proprietà di configurazione globale definita nella pipeline di versione. È possibile aggiornare il nome della versione con variabili personalizzate usando i comandi di registrazione versione

D: Come è possibile definire il periodo di conservazione per le versioni?

R: Per informazioni su come configurare i criteri di conservazione per le pipeline di versione, vedere Criteri di conservazione .