Usare i trigger per controllare quando eseguire la pipeline
È ora disponibile una pipeline funzionante che distribuisce il file Bicep nell'ambiente Azure. Tuttavia, ogni volta che si modifica il file, la pipeline deve essere eseguita manualmente. In questa unità si apprenderà come attivare la pipeline per l'esecuzione automatica ogni volta che cambia il codice Bicep.
Nota
I comandi riportati in questa unità vengono illustrati per spiegare i concetti. Non eseguire ancora i comandi. Presto sarà possibile provare quanto appreso.
Che cos'è un trigger della pipeline?
Un trigger della pipeline è una condizione che, se soddisfatta, esegue automaticamente la pipeline in base alle regole create. È possibile impostare i trigger per eseguire la pipeline a intervalli pianificati. È anche possibile impostare i trigger per eseguire la pipeline ogni volta che cambia un file nel repository. Si potrebbe scegliere la seconda opzione perché è consigliabile eseguire tutti i test e i passaggi di distribuzione ogni volta che il codice viene modificato.
Se non si usa un trigger automatico, qualcuno potrebbe apportare una modifica a un file Bicep e persino eseguirne il commit e il push nel repository. Se tuttavia dimentica di eseguire la pipeline, si creerà una differenza tra le definizioni di risorse nel file Bicep e le risorse distribuite nell'ambiente di Azure. Si supponga che un altro paio di commit e push venga eseguito, ma non distribuito. Se durante una di queste modifiche qualcuno introduce un errore o una configurazione errata nel file Bicep, potrebbe essere difficile rilevare l'errore tra i diversi commit che vengono distribuiti contemporaneamente in un secondo momento. Dopo un po' si rischia di non potersi più fidare che il codice Bicep contenga una rappresentazione fedele dell'infrastruttura, con conseguente perdita di valore.
Quando si configura la pipeline per l'esecuzione ogni volta che si aggiornano i file, nel momento in cui viene eseguito il push delle modifiche viene avviata l'esecuzione della pipeline. Si ottiene un feedback immediato sulla validità della modifica e si può essere certi che l'ambiente di produzione sia sempre aggiornato.
Trigger di ramo
Un tipo comune di trigger è un trigger di ramo, noto anche come trigger di integrazione continua o trigger CI. Quando si usa un trigger di ramo, ogni volta che si apporta una modifica a un ramo specifico, viene eseguita la pipeline. Se si eseguono il commit e il push di una modifica in un ramo diverso, la pipeline non viene attivata e non viene eseguita. È comune usare questo tipo di trigger sul ramo predefinito, o principale, con questo codice:
trigger:
- main
Trigger per la modifica di più rami
È possibile configurare trigger per eseguire la pipeline in un ramo specifico o in set di rami. Si supponga, ad esempio, di creare rami di versione contenenti il codice che verrà distribuito per una versione specifica del progetto. È possibile usare nomi di ramo come release/v1, release/v2 e così via. Si vuole eseguire la pipeline ogni volta che il codice viene modificato in un ramo che inizia con il nome release/. È possibile usare la proprietà include con un carattere jolly *:
trigger:
branches:
include:
- main
- release/*
È anche possibile escludere rami specifici. Si supponga di collaborare con i membri del team nel progetto. I colleghi creano rami di funzionalità per provare le proprie idee nei file Bicep. Tutti i rami di funzionalità hanno nomi come feature/add-database, feature/improve-performance e così via. Si vuole eseguire automaticamente la pipeline in tutti i rami, a eccezione dei rami di funzionalità creati dai colleghi. Usando la proprietà exclude, si garantisce che la pipeline non venga attivata automaticamente per le modifiche ai rami di funzionalità:
trigger:
branches:
include:
- '*'
exclude:
- feature/*
Suggerimento
Si notino le virgolette che racchiudono il carattere jolly nel filtro include. Il formato di file YAML richiede di racchiudere un singolo carattere * tra virgolette quando lo si usa come carattere jolly.
Filtri di percorso
In alcuni casi nel repository sono presenti file non correlati alla distribuzione. Ad esempio, nel repository potrebbero essere presenti una cartella deploy contenente il codice Bicep e una cartella docs separata che contiene i file della documentazione. Si vuole attivare la pipeline quando un utente apporta una modifica a uno dei file Bicep nella cartella deploy, ma non si vuole attivarla se un utente modifica solo un file di documentazione. Per configurare un trigger per rispondere alle modifiche in una cartella specifica nel repository, è possibile usare un filtro per percorsi:
trigger:
branches:
include:
- main
paths:
exclude:
- docs
include:
- deploy
Se qualcuno esegue il commit di una modifica che aggiorna solo un file di documentazione, la pipeline non viene eseguita. Ma se viene modificato un file Bicep o anche se viene modificato un file Bicep in aggiunta a un file di documentazione, il trigger esegue la pipeline.
Pianificare l'esecuzione automatica della pipeline
È possibile eseguire la pipeline in base a una pianificazione impostata e non in risposta a una modifica del file. Ad esempio, è possibile eseguire un rilascio notturno del codice Bicep o distribuire automaticamente un ambiente di test ogni mattina. Usare la parola chiave schedules invece di trigger e impostare la frequenza usando un'espressione cron:
schedules:
- cron: "0 0 * * *"
displayName: Daily environment restore
branches:
include:
- main
Nota
Un'espressione cron è una sequenza di caratteri formattata in modo speciale che imposta la frequenza con cui si verificherà un evento. In questo esempio 0 0 * * * significa esecuzione ogni giorno a mezzanotte ora UTC.
È anche possibile impostare il ramo del repository da usare nell'evento pianificato. All'avvio, la pipeline usa la versione più recente del codice del ramo impostato nella pianificazione.
Usare più trigger
È possibile combinare trigger e pianificazioni, come in questo esempio:
trigger:
- main
schedules:
- cron: "0 0 * * *"
displayName: Deploy test environment
branches:
include:
- main
Quando si creano un trigger di ramo e un trigger pianificato nella stessa pipeline, la pipeline viene eseguita ogni volta in cui un file viene modificato nel ramo impostato nel trigger e in base alla pianificazione impostata. In questo esempio la pipeline viene eseguita ogni giorno a mezzanotte ora UTC e anche ogni volta che viene eseguito il push di una modifica nel ramo main.
Suggerimento
È consigliabile impostare trigger per ogni pipeline. Se non si impostano i trigger, per impostazione predefinita la pipeline viene eseguita automaticamente ogni volta che un file cambia in qualsiasi ramo, che spesso non è un approccio desiderabile.
Controllo della concorrenza
Per impostazione predefinita, Azure Pipelines consente l'esecuzione simultanea di più istanze della pipeline. Questa situazione può verificarsi quando si effettuano più commit in un ramo entro un breve periodo di tempo.
In alcuni casi, la presenza di più esecuzioni simultanee della pipeline non è un problema. Tuttavia, quando si utilizzano le pipeline di distribuzione, può essere difficile assicurarsi che le esecuzioni della pipeline non sovrascrivano le risorse o la configurazione di Azure in modi non previsti.
Per evitare questi problemi, è possibile usare la parola chiave batch con un trigger, come in questo esempio:
trigger:
batch: true
branches:
include:
- main
Quando il trigger viene attivato, Azure Pipelines garantisce che attenda il completamento di qualsiasi esecuzione della pipeline attiva. Avvia quindi una nuova esecuzione con tutte le modifiche accumulate dall'ultima esecuzione.