Collaborare tramite le pull request
Le richieste pull consentono di comunicare ad altri utenti le modifiche di cui è stato eseguito il push in un repository GitHub.
Dopo l'invio di una richiesta pull, le parti interessate possono esaminare il set di modifiche, discutere le potenziali modifiche e persino eseguire il push dei commit di completamento, se necessario.
Le richieste pull vengono comunemente usate dai team e dalle organizzazioni che collaborano usando il modello di repository condiviso.
Tutti gli utenti condividono un singolo repository e i rami degli argomenti vengono usati per sviluppare funzionalità e isolare le modifiche.
Molti progetti open source in GitHub usano richieste pull per gestire le modifiche dai collaboratori.
Consentono di fornire un modo per notificare ai gestori del progetto le modifiche apportate.
Inoltre, iniziare la revisione del codice e la discussione generale su un set di modifiche prima di essere uniti nel ramo principale.
Le richieste pull combinano la revisione e l'unione del codice in un unico processo collaborativo.
Al termine della correzione di un bug o di una nuova funzionalità in un ramo, creare una nuova richiesta pull.
Aggiungere i membri del team alla richiesta pull in modo che possano esaminare e votare le modifiche.
Usare le richieste pull per esaminare i lavori in corso e ottenere feedback anticipato sulle modifiche.
Non c'è alcun obbligo di integrare le modifiche, poiché il proprietario può abbandonare il pull request in qualsiasi momento.
Ottenere il codice esaminato
La revisione del codice eseguita in una richiesta pull non è solo per trovare bug; questo è compito dei tuoi test.
Una buona revisione del codice rileva problemi meno evidenti che potrebbero causare problemi costosi in un secondo momento.
Le revisioni del codice aiutano a proteggere il team da unioni difettose e build falliti che sottraggono produttività al team.
La revisione rileva questi problemi prima dell'unione, proteggendo i rami essenziali da modifiche indesiderate.
Condividere le competenze e diffondere strategie di risoluzione dei problemi utilizzando una vasta gamma di revisori nel processo di revisione del codice.
La diffusione di competenze e conoscenze rende il team più solido e più resiliente.
Inviare commenti e suggerimenti eccezionali
Le recensioni di alta qualità iniziano con feedback di alta qualità. Le chiavi per ottenere un feedback ottimale in una richiesta pull sono:
- Chiedere alle persone giuste di esaminare la richiesta pull.
- Assicurarsi che i revisori sappiano cosa fa il codice.
- Dare feedback attuabile e costruttivo.
- Rispondere tempestivamente ai commenti.
Quando si assegnano revisori alla richiesta pull, assicurarsi di selezionare il set corretto di revisori.
Si vuole che i revisori conoscano il funzionamento del codice e provino a includere sviluppatori che lavorano in altre aree per condividere le proprie idee.
Inoltre, chi può fornire una descrizione chiara delle modifiche e compilare il codice con la correzione o la funzionalità in esecuzione.
I revisori devono provare a fornire commenti e suggerimenti sulle modifiche con cui non sono d'accordo. Identificare il problema e fornire un suggerimento specifico su ciò che si farebbe in modo diverso.
Questo feedback ha finalità chiare ed è facile da comprendere per il proprietario della richiesta pull.
Il proprietario della richiesta pull deve rispondere ai commenti, accettare il suggerimento o spiegare perché la modifica suggerita non è ideale.
A volte un suggerimento è valido, ma le modifiche non rientrano nell'ambito della richiesta pull.
Prendere questi suggerimenti e creare nuovi elementi di lavoro e rami di funzionalità separati dalla richiesta pull per apportare tali modifiche.
Proteggere i rami con le politiche
I repository contengono in genere uno o più rami, tra cui main, che richiedono una protezione aggiuntiva a causa della loro criticità. Azure Repos offre diversi meccanismi basati su criteri che è consigliabile implementare per raggiungere questo obiettivo.
La premessa di base di questi meccanismi consiste nell'applicare vincoli alle richieste pull. Ad esempio, è possibile includere l'applicazione di criteri di revisione del codice specifici, ad esempio la richiesta di un numero minimo di approvazioni da revisori designati prima che una richiesta pull possa essere unita. Sfruttare le competenze collettive è destinato a migliorare la qualità e l'affidabilità delle modifiche al codice.
È inoltre consigliabile implementare la politica "Verifica elementi di lavoro collegati". Ciò verifica che ogni richiesta pull sia collegata a un elemento di lavoro, fornendo contesto e promuovendo la tracciabilità. Il criterio per la risoluzione dei commenti aiuta ad assicurarsi che tutti i commenti di revisione del codice siano affrontati prima di unire il pull request.
I criteri correlati all'analisi automatica del codice, ai test e ai controlli di conformità confermano che le modifiche soddisfano gli standard predefiniti prima dell'integrazione. La limitazione dei tipi di merge consente di mantenere la cronologia dei rami di controllo. Ad esempio, si ha la possibilità di consentire solo merge *fast-forward* e *squash*.
È anche possibile imporre compilazioni pulite di nuove versioni del codice prima di consentirle di essere unite nei rami critici. In questo modo si garantisce che le modifiche unite non introducono errori di compilazione o problemi di regressione. I controlli di stato possono essere usati per rendere il completamento delle richieste pull subordinato ai segnali generati da servizi esterni. Ad esempio, questi segnali possono essere generati da Azure Pipelines che eseguono test automatizzati e analisi del codice.
Tutti i rami con criteri necessari configurati bloccano automaticamente il push diretto, applicando in modo efficace le richieste pull per tutte le modifiche. Inoltre, tali rami non possono essere eliminati.