Progettare la pipeline
In questa unità si segue il team Web di Tailspin mentre definiscono la pipeline di versione per il sito Web di Space Game .
Quando si pianifica una pipeline di versione, in genere si inizia identificando le fasi o le divisioni principali della pipeline. Ogni fase viene in genere mappata a un ambiente. Nel modulo precedente, ad esempio, la pipeline di base di Andy e Mara presentavano una fase Deploy mappata a un'istanza del servizio app Azure.
In questo modulo si alzano di livello le modifiche da una fase a quella successiva. All'interno di ogni fase, si distribuisce il sito Web Space Game nell'ambiente associato a tale fase.
Dopo aver definito le fasi necessarie, prendere in considerazione il modo in cui le modifiche vengono alzate di livello da una fase a quella successiva. Ogni fase può definire i criteri di esito positivo che devono essere soddisfatti prima che la compilazione possa passare alla fase successiva. Azure Pipelines offre diversi modi per controllare come e quando le modifiche vengono spostate nella pipeline. Nel complesso, questi approcci vengono usati per la gestione delle versioni.
In questa sezione verrà illustrato come:
- Informazioni sulle differenze tra le fasi comuni della pipeline, ad esempio Compilazione, Sviluppo, Test e Gestione temporanea.
- Informazioni su come usare i trigger manuali, pianificati e di distribuzione continua per controllare quando un artefatto deve passare alla fase successiva della pipeline.
- Vedere in che modo un'approvazione del rilascio sospende la pipeline fino a quando un responsabile approvazione non accetta o rifiuta la versione.
La riunione
L'intero team Web di Tailspin viene raccolto insieme. In Creare una pipeline di versione con Azure Pipelines il team ha pianificato le attività per lo sprint corrente. Ogni attività è correlata alla compilazione della pipeline di versione per il sito Web space game .
Tenere presente che il team ha deciso queste cinque attività per lo sprint:
- Creare una pipeline a più fasi.
- Connessione l'app Web in un database.
- Automatizzare i test di qualità.
- Automatizzare i test delle prestazioni.
- Migliorare la frequenza di rilascio.
Il team incontra per parlare della prima attività, Creare una pipeline a più fasi. Dopo aver definito la pipeline, il team può passare dal modello di verifica di base a una pipeline di versione che include più fasi, controlli di qualità e approvazioni.
Amita e Tim guardano Andy e Mara dimostrano la pipeline di versione una seconda volta. Si noterà che l'artefatto viene compilato e installato in servizio app.
Quali fasi della pipeline sono necessarie?
Quando si vuole implementare una pipeline di versione, è importante innanzitutto identificare le fasi necessarie. Le fasi scelte dipendono dai requisiti. Seguiamo il team mentre decidono le loro fasi.
Tim: OK, capisco l'idea di una pipeline automatizzata. Mi piace come è facile eseguire la distribuzione in Azure. Ma dove andiamo da questa demo? Abbiamo bisogno di qualcosa che possiamo effettivamente usare per le versioni.
Amita: Giusto! Dobbiamo aggiungere altre fasi. Attualmente, ad esempio, non è disponibile alcun posto per una fase di test.
Tim: Inoltre, abbiamo bisogno di una fase in cui possiamo mostrare le nuove funzionalità alla direzione. Non posso inviare nulla alla produzione senza l'approvazione della gestione.
Andy: Assolutamente sì! Ora che è possibile velocizzare le operazioni eseguite da una pipeline di versione, come fare questa pipeline per eseguire le operazioni necessarie?
Mara: Diamo uno schizzo ai nostri requisiti per aiutarci a pianificare i nostri passaggi successivi. Iniziamo con quello che abbiamo.
Mara si sposta sulla lavagna e disegna la pipeline esistente.
Mara: la fase di compilazione compila il codice sorgente e produce un pacchetto. In questo caso, il pacchetto è un file ZIP . La fase Distribuisci installa il file ZIP, ovvero il sito Web Space Game, in un'istanza di servizio app. Cosa manca dalla pipeline di versione?
Aggiungere la fase di sviluppo
Andy: Potrei essere distorto, ma penso che abbiamo bisogno di una fase di sviluppo . Questa fase deve essere la prima tappa per l'artefatto dopo la compilazione. Gli sviluppatori non possono sempre eseguire l'intero servizio dall'ambiente di sviluppo locale. Ad esempio, un sistema di e-commerce può richiedere un sito Web, il database dei prodotti e un sistema di pagamento. È necessaria una fase che includa tutte le esigenze dell'app.
In questo caso, la caratteristica classifica del sito Web di Space Game legge punteggi elevati da un'origine esterna. Al momento legge punteggi fittizi da un file. La configurazione di una fase di sviluppo offrirà un ambiente in cui è possibile integrare l'app Web con un database reale. Questo database potrebbe ancora contenere punteggi fittizi, ma ci porta un passo più vicino all'app finale.
Mara: Mi piace. Non si integrerà ancora con un database reale. In una fase di sviluppo , tuttavia, è possibile eseguire la distribuzione in un ambiente in cui è possibile aggiungere un database.
Mara aggiorna il suo disegno sulla lavagna. Sostituisce "Deploy" con "Dev" per mostrare la fase di sviluppo .
Andy: Si apre un punto interessante. L'app viene compilata ogni volta che si esegue il push di una modifica in GitHub. Ciò significa che ogni compilazione viene alzata di livello alla fase di sviluppo al termine?
Mara: La compilazione continua offre feedback importanti sull'integrità della compilazione e del test. Ma possiamo alzare il livello fino alla fase di sviluppo solo quando uniamo il codice in un ramo centrale, che sia un ramo principale o un altro ramo di versione. Aggiornerò il disegno per mostrare quel requisito.
Mara: Penso che questa promozione sarà facile da realizzare. È possibile definire una condizione che promuove la fase di sviluppo solo quando si verificano modifiche in un ramo di rilascio.
Quali sono le condizioni?
In Azure Pipelines usare una condizione per eseguire un'attività o un processo in base allo stato della pipeline. Si è lavorato con le condizioni nei moduli precedenti.
Tenere presente che alcune delle condizioni che è possibile specificare sono:
- Solo quando tutte le attività dipendenti precedenti hanno avuto esito positivo.
- Anche se una dipendenza precedente non è riuscita, a meno che l'esecuzione non sia stata annullata.
- Anche se una dipendenza precedente non è riuscita, anche se l'esecuzione è stata annullata.
- Solo quando una dipendenza precedente non è riuscita.
- Alcune condizioni personalizzate.
Ecco un esempio di base:
steps:
- script: echo Hello!
condition: always()
La condizione always() fa sì che questa attività stampi "Hello!" in modo incondizionato, anche se le attività precedenti non sono riuscite.
Questa condizione viene usata se non si specifica una condizione:
condition: succeeded()
La succeeded() funzione predefinita controlla se l'attività precedente è riuscita. Se l'attività precedente non riesce, questa attività e quelle successive con la stessa condizione vengono ignorate.
Qui si vuole compilare una condizione che specifica:
- L'attività precedente è riuscita.
- Il nome del ramo Git corrente è rilasciato.
Per compilare questa condizione, usare la funzione predefinita and(). Questa funzione controlla se ognuna delle relative condizioni è vera. Se una condizione non è vera, la condizione complessiva ha esito negativo.
Per ottenere il nome del ramo corrente, usare la variabile predefinita Build.SourceBranchName . È possibile accedere alle variabili all'interno di una condizione in alcuni modi. Qui si usa la variables[] sintassi .
Per testare il valore di una variabile, è possibile usare la funzione predefinita eq(). Questa funzione verifica se i relativi argomenti sono uguali.
Tenendo presente che si applica questa condizione per eseguire la fase di sviluppo solo quando il nome del ramo corrente è "release":
condition: |
and
(
succeeded(),
eq(variables['Build.SourceBranchName'], 'release')
)
La prima condizione nella funzione and() verifica se l'attività precedente ha avuto esito positivo. La seconda condizione controlla se il nome current branch è uguale a release.
In YAML si usa la sintassi pipe (|) per definire una stringa che si estende su più righe. È possibile definire la condizione per una singola riga, ma si scrive in questo modo per renderla più leggibile.
Nota
In questo modulo viene usato il ramo di rilascio come esempio. È possibile combinare le condizioni per definire il comportamento necessario. Ad esempio, è possibile compilare una condizione che esegue la fase solo quando la compilazione viene attivata da una richiesta pull nel ramo main.
Nell'unità successiva, quando si configura la fase di sviluppo , si usa un esempio più completo.
Per una descrizione più completa delle condizioni in Azure Pipelines, vedere la documentazione delle espressioni.
Mara: Usando le condizioni, è possibile controllare quali modifiche vengono alzate di livello a quali fasi. È possibile produrre un artefatto di compilazione per qualsiasi modifica per convalidare la compilazione e verificare che sia integro. Quando si è pronti, è possibile unire tali modifiche in un ramo di rilascio e alzare di livello tale compilazione alla fase di sviluppo .
Aggiungere la fase test
Mara: Finora abbiamo le fasi di compilazione e sviluppo . Cosa viene dopo?
Amita: Possiamo aggiungere la fase test successiva? Questo sembra il posto giusto per me per testare le ultime modifiche.
Mara aggiunge la fase test al disegno sulla lavagna.
Amita: Una preoccupazione che ho è la frequenza con cui ho bisogno di testare l'app. Un messaggio di posta elettronica mi invia una notifica ogni volta che Mara o Andy apporta una modifica. I cambiamenti si verificano durante tutto il giorno, e non so mai quando saltare. Penso che vorrei vedere una costruzione una volta al giorno, forse quando vado in ufficio. Possiamo farlo?
Andy: Certo. Perché non viene eseguita la distribuzione in Test durante gli orari non lavorativi? Diciamo che ti invieremo una compilazione ogni giorno alle 3.00.
Mara: Sembra buono. È sempre possibile attivare manualmente il processo anche se necessario. Ad esempio, è possibile attivarlo se è necessario verificare subito una correzione di bug importante.
Mara aggiorna il disegno per mostrare che la build passa dalla fase di sviluppo alla fase di test alle 3.00 ogni mattina.
Che cosa sono i trigger?
Amita: Mi sento meglio ora che sappiamo come una fase si muove in un'altra. Ma come si controlla quando viene eseguita una fase?
Mara: in Azure Pipelines è possibile usare i trigger. Un trigger definisce quando viene eseguita una fase. Azure Pipelines offre alcuni tipi di trigger. Ecco le nostre scelte:
- Trigger di integrazione continua (CI)
- Trigger della richiesta pull
- Trigger pianificato
- Trigger di completamento della compilazione
I trigger ci e pr consentono di controllare quali rami partecipano al processo complessivo. Si desidera, ad esempio, compilare il progetto quando viene apportata una modifica in qualsiasi ramo. Un trigger pianificato avvia una distribuzione in un momento specifico. Un trigger di completamento della compilazione esegue una compilazione quando un'altra compilazione, ad esempio una per un componente dipendente, viene completata correttamente. Sembra che si voglia un trigger pianificato.
Che cosa sono i trigger pianificati?
Un trigger pianificato usa la sintassi cron per fare in modo che una compilazione sia eseguita in base a una pianificazione definita.
Nei sistemi Unix e Linux, cron è un modo diffuso per pianificare l'esecuzione dei processi in un intervallo di tempo specificato o in un momento specifico. In Azure Pipelines i trigger pianificati usano la sintassi cron per definire quando viene eseguita una fase.
Un'espressione cron include campi che corrispondono a determinati parametri di ora. Ecco i campi:
mm HH DD MM DW
\ \ \ \ \__ Days of week
\ \ \ \____ Months
\ \ \______ Days
\ \________ Hours
\__________ Minutes
Ad esempio, questa espressione cron descrive "alle 3 ogni mattina": 0 3 * * *
Un'espressione cron può includere caratteri speciali per specificare un elenco di valori o un intervallo di valori. In questo esempio, l'asterisco (*) corrisponde a tutti i valori per i campi Days, Months e Days of week .
In un altro modo, questa espressione cron legge come:
- Al minuto 0,
- Alla terza ora,
- In qualsiasi giorno del mese,
- In qualsiasi mese,
- In qualsiasi giorno della settimana,
- Eseguire il processo
Per specificare alle 3 di mattina solo dal lunedì al venerdì, usare questa espressione: 0 3 * * 1-5
Nota
Il fuso orario per le pianificazioni cron è UTC (Coordinated Universal Time), quindi in questo esempio le 3 si riferiscono alle 3 nel fuso orario UTC. In pratica, è possibile modificare l'ora della pianificazione cron rispetto all'ora UTC in modo che la pipeline venga eseguita al momento previsto per l'utente e il team.
Per configurare un trigger pianificato in Azure Pipelines, è necessaria una schedules sezione nel file YAML. Ecco un esempio:
schedules:
- cron: '0 3 * * *'
displayName: 'Deploy every day at 3 A.M.'
branches:
include:
- release
always: false
In questa schedules sezione:
cronspecifica l'espressione cron.branchesspecifica di eseguire la distribuzione solo dalreleaseramo .alwaysspecifica se eseguire la distribuzione in modo incondizionato (true) o solo quando ilreleaseramo è cambiato dall'ultima esecuzione (false). In questo caso, è necessario eseguirefalsela distribuzione solo quando ilreleaseramo è cambiato dall'ultima esecuzione.
L'intera pipeline viene eseguita quando Azure Pipelines esegue un trigger pianificato. La pipeline viene eseguita anche in altre condizioni, ad esempio quando si esegue il push di una modifica in GitHub. Per eseguire una fase solo in risposta a un trigger pianificato, è possibile usare una condizione che controlla se il motivo della compilazione è un'esecuzione pianificata.
Ecco un esempio:
- stage: 'Test'
displayName: 'Deploy to the Test environment'
condition: and(succeeded(), eq(variables['Build.Reason'], 'Schedule'))
Questa fase, Test, viene eseguita solo quando la fase precedente ha esito positivo e la variabile della pipeline predefinita Build.Reason è uguale a Schedule.
Più avanti in questo modulo verrà visualizzato un esempio più completo.
Amita: Mi piace questo. Non devo nemmeno prelevare il rilascio manualmente e installarlo. È pronto per me.
Andy: E ricorda, se vogliamo automatizzare più tardi, possiamo. Niente è scritto in pietra. La pipeline si evolve man mano che si migliora e si apprende.
Aggiungere la fase di gestione temporanea
Tim: È il mio turno. Ho bisogno di una fase per eseguire più test di stress. Abbiamo anche bisogno di una fase in cui possiamo demo per la gestione per ottenere la loro approvazione. Per il momento, è possibile combinare queste due esigenze in una fase che è possibile chiamare Staging.
Andy: Beh, Tim. Avere un ambiente di gestione temporanea o di pre-produzione è importante. Questo ambiente di gestione temporanea è spesso l'ultimo arresto prima che una funzionalità o una correzione di bug raggiunga gli utenti.
Mara aggiunge Staging al disegno sulla lavagna.
Amita: viene usato un trigger pianificato per promuovere le modifiche dalla fase di sviluppo alla fase test . Ma come si alzano di livello le modifiche da Test a Staging? Questa promozione deve avvenire anche in base a un programma?
Mara: Penso che il modo migliore per gestire questo sarebbe un'approvazione del rilascio. Un'approvazione della versione consente di promuovere manualmente una modifica da una fase a quella successiva.
Amita: Sembra esattamente quello di cui ho bisogno! Un'approvazione della versione consente di testare le modifiche più recenti prima di presentare la compilazione alla gestione. Posso promuovere la compilazione quando sono pronto.
Mara aggiorna il disegno per mostrare che la compilazione passa da Test a Staging solo quando Amita lo approva.
Tim: Potrei anche immaginarci di usare le approvazioni di rilascio per promuovere dalla gestione temporanea alla produzione dopo che la gestione si disconnette. Non posso mai prevedere quanto tempo ci vuole. Dopo la disconnettersi, posso approvare il rilascio e alzarlo di livello alla produzione manualmente. Ma come funzionano le approvazioni di rilascio?
Che cosa sono le approvazioni del rilascio?
Un'approvazione della versione è un modo per sospendere la pipeline fino a quando un responsabile approvazione non accetta o rifiuta la versione. Per definire il flusso di lavoro di rilascio, è possibile combinare approvazioni, condizioni e trigger.
Tenere presente che in Creare una pipeline di versione con Azure Pipelines è stato definito un ambiente nella configurazione della pipeline per rappresentare l'ambiente di distribuzione. Ecco un esempio della pipeline esistente:
- stage: 'Deploy'
displayName: 'Deploy the web application'
dependsOn: Build
jobs:
- deployment: Deploy
pool:
vmImage: 'ubuntu-20.04'
environment: dev
variables:
- group: Release
L'ambiente può includere criteri specifici per la versione. I criteri possono specificare le pipeline che possono essere distribuite in tale ambiente e quali approvazioni umane sono necessarie per promuovere il rilascio da una fase all'altra.
Più avanti in questo modulo si definisce l'ambiente di gestione temporanea e ci si assegna come responsabile approvazione per alzare di livello l'app Web Space Game dalla fase test alla gestione temporanea.
Automatizzare quanto più o meno quanto necessario
Azure Pipelines offre la flessibilità necessaria per automatizzare alcune fasi, controllando manualmente le fasi che non sono pronte per l'automazione.
Tim: Mi piace come possiamo definire i criteri che promuovono i cambiamenti da una fase alla successiva. Sono stati tuttavia definiti alcuni criteri manuali nella pipeline. Pensavo che DevOps si trattasse di automatizzare tutto.
Mara: Alzate un buon punto. DevOps riguarda in realtà l'automazione di attività ripetitive e soggette a errori. A volte è necessario l'intervento umano. Ad esempio, si ottiene l'approvazione dalla gestione prima di rilasciare nuove funzionalità. Man mano che si ottiene un'esperienza maggiore con le distribuzioni automatizzate, è possibile automatizzare più passaggi manuali per velocizzare il processo. Ad esempio, è possibile automatizzare più controlli di qualità nella fase test , quindi Amita non deve approvare ogni compilazione.
Tim: Suona fantastico. Andiamo con questo piano per il momento e vediamo come possiamo velocizzare il sistema in un secondo momento.
Amita: Parlando del nostro piano, possiamo riepilogare i nostri passaggi successivi?
Il piano
Esaminiamo ora il piano del team tailspin man mano che si spostano verso i passaggi successivi.
Mara: Ecco la pipeline di versione che si vuole compilare.
Mara punta alla lavagna.
Mara: Per riepilogare, i nostri passaggi sono:
- Produrre un artefatto di compilazione ogni volta che si esegue il push di una modifica in GitHub. Questo passaggio si verifica nella fase di compilazione.
- Alzare di livello l'artefatto di compilazione alla fase di sviluppo . Questo passaggio si verifica automaticamente quando la fase di compilazione ha esito positivo e la modifica si trova nel ramo di versione.
- Alzare di livello l'artefatto di compilazione alla fase di test ogni mattina alle 3.00. Viene usato un trigger pianificato per alzare di livello automaticamente l'artefatto di compilazione.
- Alzare di livello l'artefatto di compilazione alla gestione temporanea dopo i test di Amita e approvare la compilazione. Viene usata un'approvazione della versione per alzare di livello l'artefatto di compilazione.
Dopo che la gestione approva la compilazione, è possibile distribuire l'artefatto di compilazione in un ambiente di produzione.
Amita: Sarà difficile farlo? Sembra un sacco di lavoro.
Mara: Non credo sia troppo male. Ogni fase è separata da ogni altra fase. Le fasi sono discrete. Ogni fase ha un proprio set di attività. Ad esempio, cosa accade se la fase di test rimane nella fase di test.
Ogni fase di distribuzione nella pipeline ha anche un proprio ambiente. Ad esempio, quando si distribuisce l'app in Sviluppo o Test, l'ambiente è un'istanza di servizio app.
Infine, viene testata una sola versione alla volta. Le versioni non vengono mai modificate al centro della pipeline. Nella fase di sviluppo viene usata la stessa versione della fase di gestione temporanea e ogni versione ha il proprio numero di versione. Se la versione si interrompe in una delle fasi, la correzione viene risolta e compilata di nuovo con un nuovo numero di versione. La nuova versione passa quindi attraverso la pipeline fin dall'inizio.
Alcune parole sulla qualità
Si è appena visto che il team progetta una pipeline che porta l'app fino alla compilazione alla gestione temporanea. L'intero punto di questa pipeline non è solo quello di semplificare la vita. È quello di garantire la qualità del software che distribuisce ai clienti.
Come si misura la qualità del processo di rilascio? La qualità del processo di rilascio non può essere misurata direttamente. Ciò che è possibile misurare è l'efficacia del processo. Se si modifica costantemente il processo, potrebbe essere un'indicazione che c'è qualcosa di sbagliato. Le versioni che hanno esito negativo in modo coerente in un determinato punto della pipeline potrebbero anche indicare che si è verificato un problema con il processo di rilascio.
Le versioni hanno sempre esito negativo in un determinato giorno o ora? Hanno sempre esito negativo dopo la distribuzione in un determinato ambiente? Cercare questi e altri modelli per verificare se alcuni aspetti del processo di rilascio sono dipendenti o correlati.
Un buon modo per tenere traccia della qualità del processo di rilascio consiste nel creare visualizzazioni della qualità delle versioni. Ad esempio, aggiungere un widget del dashboard che mostra lo stato di ogni versione.
Quando si vuole misurare la qualità di una versione stessa, è possibile eseguire tutti i tipi di controlli all'interno della pipeline. Ad esempio, è possibile eseguire diversi tipi di test, ad esempio test di carico e test dell'interfaccia utente durante l'esecuzione della pipeline.
L'uso di un controllo qualità è anche un ottimo modo per controllare la qualità del rilascio. Sono disponibili numerose attività di controllo della qualità diverse. Ad esempio, i controlli degli elementi di lavoro possono verificare la qualità del processo di requisiti. È anche possibile aggiungere altri controlli di sicurezza e conformità. Ad esempio, si è conformi al principio a quattro occhi o si ha la corretta tracciabilità?
Mentre si procede attraverso questo percorso di apprendimento, si noterà che molte di queste tecniche vengono messe in pratica.
Infine, quando si progetta un processo di rilascio qualitativo, considerare il tipo di documentazione o note sulla versione che è necessario fornire all'utente. Mantenere aggiornata la documentazione può essere difficile. È possibile prendere in considerazione l'uso di uno strumento, ad esempio il generatore di note sulla versione di Azure DevOps. Il generatore è un'app per le funzioni che contiene una funzione attivata tramite HTTP. Usando Archiviazione BLOB di Azure viene creato un file markdown ogni volta che viene creata una nuova versione in Azure DevOps.