Informazioni sulla convalida delle richieste pull
Quando si usano le richieste pull, è possibile assicurarsi che tutti gli aggiornamenti delle distribuzioni di Azure vengano esaminati da un'altra persona. Tuttavia, spesso è utile eseguire controlli automatizzati anche sulle modifiche al codice. In questa unità verrà illustrato come usare la convalida automatica delle richieste pull e i controlli per aumentare la fiducia del team nelle modifiche apportate al codice.
Convalida delle richieste pull
Quando si verifica una richiesta pull per il codice Bicep, è possibile eseguire alcuni passaggi comuni per valutare la modifica. I passaggi da eseguire possono includere:
- Verifica se il file Bicep contiene errori o avvisi del linter.
- Verifica che tutte le risorse definite in precedenza nel file Bicep continuino a funzionare.
- Test delle risorse appena definite per assicurarsi che vengano distribuite correttamente e che funzionino come previsto.
La convalida delle richieste pull prevede l'automazione di alcune di queste attività. Quando si automatizzano i controlli delle richieste pull, i revisori possono dedicare tempo ad altri passaggi di revisione più importanti, ad esempio per garantire che il codice soddisfi gli standard di qualità del team e che soddisfi gli obiettivi aziendali.
In un flusso di lavoro di GitHub Actions è possibile definire trigger che richiamano il flusso di lavoro in determinati punti durante il processo di richiesta pull, ad esempio quando viene creata, aggiornata, unita o chiusa una richiesta pull.
Testare il codice Bicep in un flusso di lavoro di convalida della richiesta pull
Nei moduli precedenti è stato illustrato come creare flussi di lavoro di GitHub Actions completi per il linting, la convalida, la distribuzione e il test delle modifiche all'infrastruttura di Azure e in più ambienti. Questi flussi di lavoro vengono eseguiti dopo che le modifiche vengono unite al ramo principale.
È anche possibile eseguire molte delle stesse attività in un flusso di lavoro di convalida delle richieste pull. Ad esempio:
- Il linting del codice Bicep consente di assicurarsi che il codice sia semanticamente corretto e che segua alcune procedure Bicep di base consigliate.
- La convalida preliminare consente di assicurarsi che il codice verrà distribuito correttamente, senza dover distribuire effettivamente il file. A seconda del tipo di risorsa, la convalida preliminare potrebbe cercare problemi quali nomi di risorse non validi, aree non valide per risorse specifiche e se è stata specificata una configurazione che non può essere distribuita correttamente.
- La simulazione, che elenca le modifiche che verranno apportate all'ambiente Azure in seguito alla distribuzione.
- Le distribuzioni, per distribuire effettivamente le risorse e assicurarsi che non si verifichino errori di distribuzione.
- Il test delle risorse dopo la distribuzione per assicurarsi che siano configurate in base ai requisiti aziendali.
Un flusso di lavoro di convalida delle richieste pull è un normale flusso di lavoro di GitHub Actions e può quindi eseguire tutte queste attività. Tuttavia, vale la pena definire i tipi di controlli che è necessario eseguire all'interno di una richiesta pull. Molte delle attività di convalida elencate qui richiedono l'accesso a un ambiente Azure. Ad esempio, l'operazione di simulazione confronta le risorse definite nei file Bicep con quelle nella sottoscrizione di Azure. È opportuno eseguire questo confronto con un ambiente di produzione. Tuttavia, poiché in questo modo si introduce un rischio aggiuntivo, è possibile che si preferisca non eseguire operazioni in un ambiente di produzione da un flusso di lavoro progettato per codice non ancora completato o unito.
In questo modulo si aggiungeranno due tipologie di controlli al flusso di lavoro di convalida delle richieste pull:
- Linting del codice Bicep per l'esecuzione di un set iniziale di controlli su di esso.
- Distribuzione del codice in un nuovo ambiente temporaneo.
Queste due attività non richiedono la connessione all'ambiente Azure di produzione o a uno qualsiasi dei normali ambienti non di produzione, ad esempio test, controllo di qualità o staging. Con queste due attività, si aumenta comunque la fiducia nelle modifiche al codice affinché sia possibile unirle nel ramo principale del repository.
I controlli sono utili per i revisori, perché consentono di risparmiare tempo che altrimenti verrebbe impiegato per eseguire manualmente le attività. I controlli sono utili anche per l'utente, come autore della richiesta pull, perché è possibile usarli per ottenere una panoramica iniziale del modo in cui funzioneranno le modifiche successivamente nel processo di distribuzione.
Nei flussi di lavoro di convalida delle richieste pull personalizzati è possibile scegliere di estendere i controlli di convalida con attività aggiuntive.
Trigger del ciclo di vita delle richieste pull
Una richiesta pull in GitHub può passare attraverso molti eventi del ciclo di vita diversi. Ad esempio, una richiesta pull viene aperta. L'autore potrebbe quindi eseguire il push delle modifiche nel ramo di origine (sincronizzazione), che influisce sul contenuto della richiesta pull. Successivamente, la richiesta pull può essere unita, chiusa senza essere unita e anche riaperta in futuro.
Con GitHub Actions è possibile definire trigger del flusso di lavoro che rispondono a tutti questi eventi. Ad esempio, è possibile definire un flusso di lavoro che viene eseguito automaticamente ogni volta che viene aperta, sincronizzata o riaperta una richiesta pull specificando il trigger pull_request senza alcuna configurazione aggiuntiva:
on: pull_request
È anche possibile specificare eventi di richiesta pull che attivano un flusso di lavoro. Ad esempio, il flusso di lavoro seguente viene eseguito automaticamente ogni volta che viene chiusa una richiesta pull:
on:
pull_request:
types: [closed]
Importante
Se si verificano conflitti di unione in una richiesta pull, il flusso di lavoro non verrà eseguito. È necessario risolvere il conflitto ed eseguire il push della risoluzione per consentire l'esecuzione del flusso di lavoro.
Controlli di stato delle richieste pull
I risultati di un flusso di lavoro di richiesta pull vengono visualizzati nella pagina dei dettagli della richiesta pull come controlli. I controlli consentono agli autori e ai revisori di ottenere rapidamente feedback sull'esito positivo o negativo delle attività automatizzate, come illustrato nell'esempio seguente:
Per impostazione predefinita, anche se un controllo ha esito negativo, è possibile unire la richiesta pull. Se si preferisce non consentire questo comportamento, è possibile configurare regole di protezione del ramo per imporre l'esito positivo di controlli specifici prima che una richiesta pull possa essere unita.
Aggiornamento dei file
Dopo aver creato una richiesta pull, è comune che venga aggiornata dall'autore. Ad esempio:
- Un revisore potrebbe chiedere all'autore di apportare modifiche al codice.
- Se un controllo automatico ha esito negativo, l'autore può modificare il codice per risolvere il problema e quindi eseguire il commit e il push delle modifiche.
Usando il trigger pull_request, è possibile configurare il flusso di lavoro di convalida per l'esecuzione ogni volta che il ramo di origine viene aggiornato. I risultati dell'esecuzione più recente del flusso di lavoro vengono visualizzati nella pagina dei dettagli della richiesta pull.
Flussi di lavoro riutilizzabili
Se si esamina l'elenco dei controlli possibili per la convalida delle richieste pull, si noterà che si tratta degli stessi passaggi eseguiti in un normale flusso di lavoro di distribuzione. Per evitare ripetizioni, è consigliabile usare i flussi di lavoro riutilizzabili di GitHub.
È possibile definire flussi di lavoro riutilizzabili per ognuno dei processi che verranno usati nelle varie definizioni del flusso di lavoro. Si vedrà come eseguire questa operazione nell'esercizio successivo.
Bozze di richieste pull
In qualità di autore, si apre in genere una richiesta pull quando si è pronti per la revisione, l'approvazione e l'unione delle modifiche. Può tuttavia essere utile ottenere l'accesso ai controlli di convalida automatica delle richieste pull durante il processo di scrittura del codice, anche se non si è ancora pronti per l'unione delle modifiche.
Quando si apre una richiesta pull in GitHub, è possibile contrassegnarla come bozza. GitHub esegue tutti gli stessi controlli automatizzati e i revisori possono comunque fornire un feedback. Quando la richiesta pull è in stato bozza, tuttavia, è chiaro a tutti che non è ancora pronta per una revisione completa e non può essere unita.
È particolarmente comune creare richieste pull bozza quando il flusso di lavoro di convalida delle richieste pull crea ambienti temporanei, perché è possibile visualizzare in anteprima le modifiche in un ambiente live funzionante. Man mano che si continua a eseguire il push delle modifiche, l'ambiente temporaneo viene aggiornato per incorporare le modifiche più recenti.