Esaminare e unire le modifiche Bicep
Si è appreso come usare i rami di funzionalità e come applicare la protezione dei rami per assicurarsi che le modifiche vengano esaminate prima di essere unite. È ora necessario seguire un processo coerente per proporre ed esaminare le modifiche prima che vengano unite.
In questa unità verranno fornite altre informazioni sulle richieste pull, tra cui come creare e usarle. Si apprenderà anche come usare le richieste pull per esaminare il codice Bicep.
Richieste pull
Una richiesta pull è una richiesta da parte dell'utente, lo sviluppatore di una funzionalità, al gestore del ramo principale. Si chiede al gestore di eseguire il pull delle modifiche nel ramo principale del repository.
Richieste pull e protezioni dei rami
Quando si configurano le protezioni dei rami, è possibile richiedere ai proprietari del codice di esaminare la richiesta pull. Ad esempio, è possibile includere i lead del progetto come revisori per tutte le richieste pull oppure specificare che un determinato numero di persone deve esaminare ogni richiesta pull.
Richieste pull e criteri dei rami
Quando si configurano i criteri dei rami, è possibile richiedere a persone specifiche o a un gruppo di persone di esaminare la richiesta pull. Ad esempio, è possibile includere i lead del progetto come revisori per tutte le richieste pull oppure specificare che un determinato numero di persone deve esaminare ogni richiesta pull.
È anche possibile richiedere che ogni richiesta pull sia collegata a un elemento di lavoro. Usando questa configurazione, è possibile eseguire la traccia da un elemento di lavoro che contiene una richiesta di funzionalità al codice che implementa la modifica fino alla distribuzione nell'ambiente di produzione.
Crea una richiesta pull
È possibile creare una richiesta pull usando l'interfaccia Web di GitHub. Si seleziona il ramo di origine in cui sono state apportate le modifiche e il ramo di destinazione che in genere è il ramo principale del repository.
È possibile creare una richiesta pull usando l'interfaccia Web di Azure DevOps. Si seleziona il ramo di origine in cui sono state apportate le modifiche e il ramo di destinazione che in genere è il ramo principale del repository.
Quando si crea una richiesta pull, è necessario assegnargli un nome. È consigliabile rendere chiari e comprensibili i nomi delle richieste pull. Questa procedura consente ai membri del team di comprendere il contesto di ciò che viene chiesto di esaminare. Se hanno diverse aree di competenza, un buon nome può aiutare a trovare richieste pull in cui possono contribuire con feedback significativi e ignorare le richieste pull che non sono pertinenti.
Inoltre, i nomi delle richieste pull spesso diventano parte della cronologia del repository Git, quindi è consigliabile renderli comprensibili quando qualcuno esamina la cronologia.
È anche possibile assegnare richieste pull a una descrizione. È possibile menzionare persone specifiche o fare riferimento a problemi nelle descrizioni. Molti team creano modelli standardizzati per le descrizioni delle richieste pull in modo che sia chiaro il contenuto di ogni modifica.
È anche possibile assegnare richieste pull a una descrizione. È possibile menzionare persone specifiche o fare riferimento a elementi di lavoro nelle descrizioni. Molti team creano modelli standardizzati per le descrizioni delle richieste pull in modo che sia chiaro il contenuto di ogni modifica.
Quando si crea una richiesta pull, è possibile invitare persone a esaminare le modifiche.
A volte si crea una richiesta pull solo per ottenere feedback dai colleghi. In queste situazioni è possibile specificare che la richiesta pull è una bozza. I revisori sapranno che si sta ancora lavorando alle modifiche. I revisori possono comunque fornire feedback, ma è chiaro che le modifiche non sono ancora pronte per l'unione. Quando si è soddisfatti delle modifiche, è possibile rimuovere lo stato di bozza.
Anche dopo aver creato una richiesta pull, è possibile continuare ad apportare modifiche al codice nel ramo di funzionalità. Queste modifiche diventano parte della richiesta pull.
Esaminare una richiesta pull
Quando si esamina una richiesta pull, è possibile visualizzare tutte le modifiche. È possibile commentare l'intera richiesta pull o solo in parti specifiche dei file modificati. L'autore della richiesta pull può rispondere ai commenti e altri revisori possono partecipare alle discussioni. Queste funzionalità di commento consentono di collaborare alle richieste pull in un'esperienza interattiva.
Quando si esamina il codice Bicep, cercare questi elementi chiave:
- È possibile distribuire il file? Distribuire e testare il codice Bicep prima che venga unito. Assicurarsi che non siano presenti avvisi linter e che la distribuzione di Azure abbia esito positivo. In un modulo microsoft Learn futuro verranno illustrati gli approcci per distribuire e verificare automaticamente le modifiche.
- Il codice Bicep è chiaro e comprensibile? È importante che tutti i membri del team comprendano il codice Bicep. Quando si esamina un file Bicep in una richiesta pull, assicurarsi di comprendere esattamente a cosa serve ogni modifica. Le variabili e i parametri sono denominati correttamente? Sono stati usati i commenti per spiegare le sezioni complesse del codice?
- La modifica è completa? Se questa richiesta pull rappresenta parte di un lavoro più ampio, assicurarsi che l'ambiente funzioni quando questa modifica viene unita e distribuita. Ad esempio, se la richiesta pull riconfigura una risorsa di Azure in preparazione a una modifica successiva, verificare che la risorsa continui a funzionare correttamente nell'intero processo. Se la richiesta pull aggiunge una nuova risorsa di Azure che non è ancora necessaria, valutare se deve essere aggiunta temporaneamente una condizione in modo che la risorsa non venga distribuita finché non è necessaria.
- La modifica segue le procedure Bicep valide? In altri moduli di Microsoft Learn sono stati illustrati gli elementi del codice Bicep valido. Assicurarsi che il codice esaminato segua le stesse procedure consigliate.
- La modifica corrisponde alla descrizione? È consigliabile che le richieste pull includano un titolo descrittivo. Molti team richiedono anche che le richieste pull includano una descrizione della modifica e il relativo scopo. Verificare che le modifiche apportate al codice Bicep corrispondano ai dettagli della richiesta pull. Se l'autore della richiesta pull ha collegato elementi di lavoro o problemi, verificare che le modifiche nella richiesta pull soddisfino i criteri di esito positivo definiti dall'elemento di lavoro.
Completare una richiesta pull
Dopo l'approvazione, la richiesta pull può essere completata. Ciò significa che il contenuto della richiesta pull viene unito al ramo principale.
In alcuni team, anche l'autore della richiesta pull deve completarla. Questo processo consente di assicurarsi che l'autore controlli quando si verifica l'unione e possa essere disponibile per monitorare le distribuzioni automatizzate. In altri team, i responsabili dell'approvazione completano la richiesta pull. Il team deve decidere chi unisce le richieste pull e quando.
In alcuni team, anche l'autore della richiesta pull deve completarla. Questo processo consente di assicurarsi che l'autore controlli quando si verifica l'unione e possa essere disponibile per monitorare le distribuzioni automatizzate. In altri team, i responsabili dell'approvazione completano la richiesta pull. È anche possibile usare Azure DevOps per completare automaticamente una richiesta pull quando soddisfa i criteri di approvazione. Il team deve decidere chi unisce le richieste pull e quando.
Processo del team
Dopo aver iniziato a usare rami di funzionalità e richieste pull, il processo del team potrebbe cambiare in modo simile al seguente:
Un membro del team clona il repository condiviso.
Apporta delle modifiche locali a un ramo, nella propria copia locale del repository.
Al termine delle modifiche, esegue il push del ramo locale nel repository condiviso.
All'interno del repository condiviso crea una richiesta pull per unire il ramo al ramo principale.
Altri membri del team esaminano le modifiche. Quando sono soddisfatti, approvano la richiesta pull e questa viene unita al ramo principale del repository condiviso.
Elimina i rami nel repository condiviso e nella copia locale del repository.
In alcuni scenari, l'esecuzione del push nel repository remoto attiva una pipeline automatizzata per verificare, testare e implementare il codice. Informazioni aggiuntive sulle pipeline sono disponibili in altri moduli di Microsoft Learn.
Nella seguente figura viene illustrato questo processo rivisto.
