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:
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.
Processo di distribuzione della coda:
Azure Pipelines pianifica il processo di distribuzione in un agente disponibile.
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.
Scaricare gli artefatti:
L'agente recupera e scarica tutti gli artefatti specificati nella versione.
Eseguire le attività di distribuzione:
L'agente esegue tutte le attività nel processo di distribuzione.
Generare i log di stato:
L'agente genera log completi per ogni passaggio di distribuzione e li invia ad Azure Pipelines.
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.
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.
Versioni e distribuzioni
Una versione è un costrutto che contiene un set di elementi con controllo delle versioni specificato in una pipeline CI/CD. Include uno snapshot di tutte le informazioni necessarie per eseguire tutte le attività e le azioni nella pipeline di versione, ad esempio fasi, attività, criteri come trigger e responsabili approvazione e opzioni di distribuzione. Possono essere presenti più versioni da una pipeline di versione e le informazioni su ognuna vengono archiviate e visualizzate in Azure Pipelines per il periodo di conservazione specificato.
Una distribuzione è l'azione di esecuzione delle attività per una fase, che può includere l'esecuzione di test automatizzati, la distribuzione degli artefatti di compilazione e qualsiasi altra azione specificata per tale fase. L'avvio di una versione avvia ogni distribuzione in base alle impostazioni e ai criteri definiti nella pipeline di versione originale. Possono essere presenti più distribuzioni di ogni versione anche per una fase. Quando una distribuzione di una versione non riesce per una fase, è possibile ridistribuire la stessa versione in tale fase. Per ridistribuire una versione, passare semplicemente alla versione che si vuole distribuire e selezionare Distribuisci.
Il diagramma seguente illustra la relazione tra versioni, pipeline di versione e distribuzioni.
Domande frequenti
D: Perché la distribuzione non è stata attivata?
R: La creazione di una pipeline di versione non avvia automaticamente una distribuzione. Ecco alcuni motivi per cui questo problema può verificarsi:
Trigger di distribuzione: i trigger di distribuzione definiti possono causare la sospensione della distribuzione. Ciò può verificarsi con i trigger pianificati o quando si verifica un ritardo fino al completamento della distribuzione in un'altra fase.
Criteri di accodamento: questi criteri determinano l'ordine di esecuzione e quando le versioni vengono accodate per la distribuzione.
Approvazioni pre-distribuzione o controlli: fasi specifiche possono richiedere approvazioni o controlli pre-distribuzione, impedendo la distribuzione fino a quando non vengono soddisfatte tutte le condizioni definite.
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.
Successivamente, quando si genera una nuova versione, è possibile modificare i valori di tali variabili.
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.
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 .