Implementare restrizioni di unione dei rami

Completato

Le restrizioni di unione dei rami nei sistemi di controllo della versione ospitati da Azure DevOps e GitHub sono essenziali per controllare la qualità del codice, facilitare la collaborazione e migliorare la stabilità nei progetti di sviluppo software. Consentono alle organizzazioni di applicare revisioni del codice, convalidare il completamento corretto dei test automatizzati e impedire il push forzato nei rami designati. Questi vincoli consentono di mantenere l'integrità della codebase, impedire modifiche accidentali e assicurarsi che solo le modifiche verificate e approvate vengano unite nei rami di produzione.

I concetti generali di restrizioni nell'unione dei rami sono indipendenti dalla piattaforma. Anche se l'implementazione differisce in qualche modo tra Azure DevOps e GitHub, esistono anche molte analogie, fornendo, per la maggior parte, la parità delle funzionalità tra di esse.

Azure DevOps

In Azure DevOps è possibile implementare restrizioni di unione dei rami usando i criteri basati sulla protezione dei rami.

Per implementare la protezione dei rami, passare al repository nel portale di Azure DevOps e selezionare il ramo a cui applicare le restrizioni di unione. In alternativa, è possibile definire l'ambito di protezione per i rami correnti e futuri che corrispondono a un modello specificato. Come parte della configurazione di protezione, è possibile applicare i criteri di ramo seguenti:

• Richiedi un numero minimo di revisori: garantisce che le modifiche non possano essere unite senza il numero necessario di approvazioni.
• Verificare la presenza di elementi di lavoro collegati: incoraggia la tracciabilità controllando la presenza di elementi collegati nelle richieste pull
• Controllare la risoluzione dei commenti: verifica che tutti i commenti siano stati risolti nelle pull request
• Limitare i tipi di merge: controlla la cronologia dei rami limitando i tipi di merge disponibili al termine delle richieste pull. Ciò include l'opzione per abilitare o disabilitare in modo selettivo i tipi di unione seguenti:
  • unione di base (senza avanzamento rapido): mantiene la cronologia esattamente come è accaduto durante lo sviluppo.
  • Rebase e fast-forward: crea una cronologia lineare riproducendo i commit del ramo di origine sul ramo di destinazione senza un commit di merge.
  • Squash merge (operazione di squash merge): Crea una cronologia lineare condensando i commit del ramo di origine in un singolo nuovo commit nel ramo di destinazione.
  • Rebase con commit di merge: Crea una cronologia semi-lineare riproducendo i commit del ramo di origine sul ramo di destinazione e quindi creando un commit di merge.

Facoltativamente, è possibile configurare i vincoli seguenti:

• validazione della build: convalida il codice mediante l'unione preliminare e la compilazione delle modifiche della pull request.
• Controlli di stato: richiedono ad altri servizi di pubblicare uno stato positivo per completare le richieste di pull. I controlli di stato sono attività automatizzate attivate durante il processo di richiesta pull per verificare determinati criteri prima di consentire il merge della richiesta pull nel ramo di destinazione. In Azure DevOps i controlli di stato sono associati alle pipeline di compilazione e alle pipeline di versione.
• Includi automaticamente revisori: designare revisori del codice da includere automaticamente quando le richieste pull modificano determinate aree di codice.

È anche possibile bloccare un ramo, rendendolo di sola lettura.

Si noti che Azure DevOps offre due opzioni per ignorare i requisiti dei criteri per un repository. Per implementarle, è necessario modificare la configurazione di sicurezza predefinita del repository impostando le autorizzazioni per eseguire le azioni seguenti su Consenti:

• Ignorare i criteri durante il completamento delle richieste pull.
• Ignorare i criteri durante il push.

È essenziale assicurarsi che queste autorizzazioni vengano concesse solo agli utenti designati che comprendono le implicazioni di queste azioni sulla conformità agli standard dell'organizzazione e possono esercitare un giudizio valido riguardo al loro uso.

GitHub

In GitHub è possibile implementare restrizioni di unione dei rami usando le regole di protezione dei rami. Le regole di protezione dei rami definiscono se i collaboratori possono eliminare o forzare il push nel ramo e impostare i requisiti per eventuali push nel ramo, ad esempio il passaggio di controlli di stato o una cronologia di commit lineare. Come con Azure DevOps, è possibile applicarli a rami specifici in base alla corrispondenza del modello di nome.

Per implementare le regole di protezione dei rami, passare al repository nell'interfaccia Web di GitHub, nella scheda Impostazioni e, nel menu di spostamento, selezionare la voce di menu Rami. In questo modo sarà possibile accedere alla configurazione delle regole di protezione dei rami. Come parte della configurazione di protezione, è possibile applicare le regole seguenti:

• Richiedi una richiesta pull prima dell'unione: richiede che i collaboratori inviino richieste pull per la revisione e l'approvazione prima di unire le modifiche.
• Richiedi controlli di stato da passare prima dell'unione: designa i controlli di stato che devono essere passati prima di consentire l'unione. Se abilitato, i commit devono prima essere inseriti in un altro ramo, quindi uniti o inseriti direttamente in un ramo che corrisponde a questa regola dopo il superamento dei controlli di stato.
• Richiedi risoluzione della conversazione prima dell'unione: garantisce che tutte le discussioni e i commenti correlati alle modifiche al codice vengano risolti prima di unire le richieste pull.
• Richiedi commit firmati: stabilisce che i commit inviati nei rami protetti vengano firmati con firme verificate, migliorando la sicurezza e garantendo l'autenticità dei contributi di codice.
• Richiedi cronologia lineare: impedisce il commit di merge in rami protetti, applicando una cronologia lineare, che semplifica il rilevamento e, se necessario, inverte eventuali modifiche. Ciò significa che tutte le richieste pull devono usare un merge di squash o un merge di rebase.
• Richiedi che le distribuzioni abbiano esito positivo prima dell'unione: determina che le modifiche proposte nelle richieste pull vengono testate e convalidate accuratamente prima di essere integrate nella codebase.
• Blocca il branch: come il suo equivalente in Azure Devops, limita l'accesso in scrittura al branch, rendendolo di sola lettura.
• Non consentire di ignorare le impostazioni precedenti: elimina la possibilità che altre regole vengano ignorate dagli amministratori e dagli utenti a cui viene concessa l'autorizzazione a ignorare le protezioni dei rami.
• Consenti push forzato: consentire agli utenti con privilegi di push di eseguire push forzati. Come per Azure DevOps, si tratta solo di una misura di emergenza.
• Consenti eliminazioni: consente agli utenti con privilegi push di eliminare rami protetti. Sebbene questa flessibilità possa semplificare la gestione dei rami, comporta anche un rischio di eliminazioni accidentali o dannose dei rami e deve essere controllata attentamente per evitare la perdita di dati e mantenere l'integrità del repository.