Pipeline di rilascio classiche
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 distribuzione
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.
Job di distribuzione della coda
Azure Pipelines pianifica il processo di distribuzione in un agente disponibile.
Selezione dell'agente:
Un agente disponibile accetta il processo di distribuzione. Una pipeline di versione può essere configurata per selezionare dinamicamente un agente appropriato durante il runtime.
Scarica 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 progresso:
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 varietà di fonti di 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
Un rilascio è un costrutto che contiene un insieme di artefatti versionati specificato in una pipeline CI/CD. Includere uno snapshot di tutte le informazioni necessarie per eseguire le attività nella pipeline di rilascio, ad esempio fasi, criteri come trigger e responsabili delle approvazioni 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 Impostabile in fase di rilascio per le variabili che si desidera modificare quando viene messo in coda un rilascio.
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 >>Abbandonare. Non è possibile abbandonare una versione quando è in corso una distribuzione, è prima necessario annullare la distribuzione.
D: Come gestisco i nomi delle nuove release?
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 rilascio, 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 autoincrementato con un numero di cifre almeno pari a quello specificato. |
| Data/Data: ddMMyy | Data corrente, con il formato predefinito MMddyy. Sono supportate tutte le combinazioni di M/MM/MMM/MMMM, d/dd/ddd/dddd, y/yy/yyyy/yyyy, h/hh/H/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 rilascio a cui appartiene il rilascio corrente. |
| Build.BuildNumber | Numero della build contenuto nel rilascio. 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 build primaria. |
| Artifact.ArtifactType | Tipo della sorgente dell'artefatto associato al rilascio. Ad esempio, può trattarsi di Azure Pipelines o Jenkins. |
| Build.SourceBranch | Ramo della fonte dell'artefatto primario. Per Git, si tratta del formato principale se il ramo è refs/heads/main. Per il controllo della versione di Team Foundation, questo è nella forma branch 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 della versione |
Q: Come posso definire il periodo di conservazione per le mie versioni?
R: Per informazioni su come configurare i criteri di conservazione per le pipeline di versione, vedere Criteri di conservazione .