Condividi tramite

Criteri e impostazioni dei rami

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

I criteri dei rami aiutano i team a proteggere i rami importanti dello sviluppo. Le politiche applicano gli standard del team sulla qualità del codice e sulla gestione delle modifiche. Questo articolo descrive come impostare e gestire i criteri dei rami. Per una panoramica di tutti i criteri e le impostazioni dei repository e dei rami, vedere Impostazioni e criteri del repository Git.

Un ramo con i criteri necessari configurati non può essere eliminato e richiede richieste pull per tutte le modifiche.

Prerequisiti

  • Per impostare i criteri di filiale, devi essere membro del gruppo di sicurezza Project Administrators o disporre delle autorizzazioni di modifica a livello di repository sui criteri . Per altre informazioni, vedere Impostare le autorizzazioni del repository Git.

Configurare le politiche dei rami

Per gestire i criteri dei rami, selezionare Repos>Rami per aprire la pagina Rami nel Portale Web.

Screenshot che mostra la voce di menu Filiali.

È anche possibile accedere alle impostazioni dei criteri del ramo con Impostazioni del progetto>Repository>Criteri>Criteri del ramo><Nome del ramo>.

I rami con criteri visualizzano un'icona dei criteri. È possibile selezionare l'icona per passare direttamente alle impostazioni dei criteri del ramo.

Per impostare i criteri di ramo, individuare il ramo che si vuole gestire. È possibile esplorare l'elenco o cercare la tua filiale nella casella Cerca nome ramo in alto a destra.

Selezionare l'icona Altre opzioni accanto al ramo e quindi selezionare Criteri ramo dal menu di scelta rapida.

Screenshot che mostra come aprire le politiche dei branch dal menu di scelta rapida.

Configurare i criteri nella pagina delle impostazioni del ramo. Vedere le sezioni seguenti per le descrizioni e le istruzioni per ogni tipo di criterio.

Richiedere un numero minimo di revisori

Le revisioni del codice sono importanti per i progetti di sviluppo software. Per assicurarsi che i team esaminino e approvino i pull request, puoi richiedere l'approvazione da un numero minimo di revisori. I criteri di base richiedono che un numero specificato di revisori approvi il codice, senza rifiuto.

Per impostare i criteri, in Criteri di ramo impostare Richiedi un numero minimo di revisori su Sì. Immettere il numero richiesto di revisori e selezionare una delle opzioni seguenti:

Screenshot che mostra il criterio Richiedi revisioni codice.

  • Selezionare Consenti ai richiedenti di approvare le proprie modifiche per consentire all'autore di una richiesta pull di votarne l'approvazione. In caso contrario, l'autore può comunque votare Approva sulla pull request, ma il loro voto non viene conteggiato nel numero minimo di revisori.

  • Selezionare Impedisci al pusher più recente di approvare le proprie modifiche per applicare la separazione dei compiti. Per impostazione predefinita, chiunque disponga dell'autorizzazione push nel ramo di origine può sia aggiungere commit sia votare per l'approvazione della pull request. Se si seleziona questa opzione, il voto del pusher più recente non viene conteggiato, anche se in genere può approvare le proprie modifiche.

  • Selezionare Consenti completamento anche se alcuni revisori votano per attendere o rifiutare per permettere il completamento della richiesta pull anche se alcuni revisori votano contro. Il numero minimo di revisori deve comunque approvare.

  • Sotto Quando vengono inviate nuove modifiche:
    • Selezionare Richiedi almeno un'approvazione nell'ultima iterazione per richiedere almeno un voto di approvazione per l'ultima modifica del ramo di origine.
    • Selezionare Reimposta tutti i voti di approvazione (non reimposta i voti per rifiutare o attendere) per rimuovere tutti i voti di approvazione, ma mantenere i voti da rifiutare o attendere ogni volta che il ramo di origine cambia.
    • Selezionare Reimposta tutti i voti dei revisori del codice per rimuovere tutti i voti dei revisori ogni volta che il ramo sorgente cambia, inclusi i voti per approvazione, rifiuto o attesa.
  • Sotto Quando vengono eseguite nuove modifiche:
    • Selezionare Richiedi almeno un'approvazione per ogni iterazione per richiedere almeno un voto di approvazione per l'ultima modifica del ramo di origine. L'approvazione dell'utente non viene conteggiata rispetto a qualsiasi iterazione precedente non approvata di cui è stato eseguito il push da tale utente. Di conseguenza, è necessaria un'altra approvazione per l'ultima iterazione da parte di un altro utente. Richiedere almeno un'approvazione per ogni iterazione è disponibile in Azure DevOps Server 2022.1 e versioni successive.
    • Selezionare Richiedi almeno un'approvazione nell'ultima iterazione per richiedere almeno un voto di approvazione per l'ultima modifica del ramo di origine.
    • Selezionare Reimposta tutti i voti di approvazione (non reimposta i voti per rifiutare o attendere) per rimuovere tutti i voti di approvazione, ma mantenere i voti da rifiutare o attendere ogni volta che il ramo di origine cambia.
    • Selezionare Reimposta tutti i voti dei revisori del codice per rimuovere tutti i voti dei revisori ogni volta che il ramo sorgente cambia, inclusi i voti per approvazione, rifiuto o attesa.

Se tutti gli altri criteri vengono rispettati, l'autore può completare la pull request quando viene approvata dal numero richiesto di revisori.

Verificare la presenza di elementi di lavoro collegati

Per il monitoraggio della gestione degli elementi di lavoro, è possibile richiedere associazioni tra le richieste pull e gli elementi di lavoro. Il collegamento degli elementi di lavoro offre più contesto per le modifiche e garantisce che gli aggiornamenti vengano sottoposti al processo di rilevamento degli elementi di lavoro.

Per impostare i criteri, in Criteri di ramo, imposta Controlla la presenza di elementi di lavoro collegati su Attivo. Questa impostazione richiede di collegare gli elementi di lavoro a una richiesta pull per l'unione della stessa. Impostare l'impostazione Facoltativo per avvisare quando non sono presenti elementi di lavoro collegati, ma consentire il completamento della richiesta pull.

Schermata di richiedere elementi di lavoro collegati nei pull request.

Verificare la risoluzione dei commenti

Il criterio Check for comment resolution controlla se tutti i commenti delle pull request sono risolti.

Configurare un criterio di risoluzione dei commenti per il ramo impostando Verifica la risoluzione dei commenti su Sì. Selezionare quindi se impostare il criterio Obbligatorio o Facoltativo.

Screenshot di Verifica della risoluzione dei commenti.

Per ulteriori informazioni sull'uso dei commenti nelle pull request, vedere Esaminare le pull request.

Limitare i tipi di unione

Azure Repos include diverse strategie di merge e, per impostazione predefinita, sono consentite tutte. È possibile mantenere una cronologia coerente dei rami applicando una strategia di merge per il completamento della pull request.

Impostare Limita tipi di unione su Sì per limitare i tipi di unione da consentire nel repository.

Screenshot di

  • L'unione di base (senza fast-forward) crea un commit di unione nella destinazione i cui genitori sono i rami di destinazione e di origine.
  • Il squash merge crea una cronologia lineare con un singolo commit nel ramo di destinazione contenente le modifiche del ramo di origine. Altre informazioni sull'unione di squash e su come influisce sulla cronologia dei rami.
  • Rebase e fast-forward crea una cronologia lineare riproducendo i commit di origine nel ramo di destinazione senza commit di merge.
  • Il rebase con commit di merge ripete i commit dalla fonte sul bersaglio e crea anche un commit di merge.

Validazione della build

È possibile impostare un criterio che richiede modifiche alla richiesta pull per essere compilate correttamente prima del completamento della richiesta pull. Le politiche di costruzione riducono le interruzioni e mantengono i risultati dei test positivi. Anche i criteri di compilazione sono utili se si usa l'integrazione continua nei rami di sviluppo per individuare problemi tempestivamente.

Un criterio di convalida della compilazione accoda una nuova compilazione quando viene creata una nuova richiesta pull o le modifiche vengono inoltrate a una richiesta pull esistente destinata al ramo. La politica di compilazione valuta i risultati della compilazione per determinare se la richiesta pull può essere completata.

Importante

Prima di specificare un criterio di convalida della compilazione, assicurati di avere una pipeline di compilazione. Se non hai la pipeline, vedi Creare una pipeline di compilazione. Scegli il tipo di compilazione che corrisponde al tipo di progetto.

Per aggiungere un criterio di verifica della build

  1. Selezionare il pulsante + accanto a Convalida compilazione.

    Screenshot che mostra il pulsante Aggiungi accanto a Convalida compilazione.

  2. Compilare il modulo Imposta criteri di compilazione :

    Screenshot delle impostazioni delle politiche di build.

    • Selezionare la pipeline di compilazione.

    • È possibile impostare facoltativamente un filtro Percorso. Scopri di più sui filtri di percorso nelle policy di ramo.

    • In Trigger selezionare Automatico (ogni volta che il ramo di origine viene aggiornato) o Manuale.

    • In Requisito dei criteri selezionare Obbligatorio o Facoltativo. Se si sceglie Obbligatorio, le compilazioni devono essere completate correttamente per completare i pull request. Scegliere Facoltativo per fornire una notifica dell'errore di compilazione e consentire comunque il completamento delle pull request.

    • Imposta una scadenza della build per garantire che gli aggiornamenti al tuo ramo protetto non interrompano le modifiche per i pull request aperti.

      • Immediatamente quando < il nome del ramo> viene aggiornato: questa opzione imposta lo stato della politica di build PR su non riuscita ogni volta che il ramo viene aggiornato e accoda nuovamente una compilazione. Questa impostazione garantisce che le modifiche alla richiesta di pull vengano compilate con successo anche se il ramo protetto cambia.

        Questa opzione è ideale per i team i cui rami importanti hanno poche modifiche. I gruppi che lavorano in rami di sviluppo molto attivi potrebbero trovare disturbante dover aspettare per una build ogni volta che il ramo si aggiorna.

      • Dopo <n> ore se <il nome del ramo> è stato aggiornato: questa opzione fa scadere lo stato attuale della policy quando il ramo protetto viene aggiornato se la build riuscita è più vecchia della soglia immessa. Questa opzione è un compromesso tra richiedere sempre o mai un build quando il ramo protetto viene aggiornato. Questa scelta riduce il numero di compilazioni quando il branch protetto è aggiornato frequentemente.

      • Mai: gli aggiornamenti al ramo protetto non modificano lo stato della politica. Questo valore riduce il numero di compilazioni, ma può causare problemi durante il completamento delle richieste di pull che non sono state aggiornate di recente.

    • Immettere un nome visualizzato facoltativo per questo criterio di compilazione. Questo nome identifica la politica su Pagina criteri del ramo. Se non si specifica un nome visualizzato, la politica utilizza il nome della pipeline di compilazione.

  3. Seleziona Salva.

Quando il proprietario della pull request effettua il push delle modifiche che vengono compilate correttamente, lo stato della politica si aggiorna.

Se si dispone di un criterio di compilazione Immediatamente quando <il nome del ramo> viene aggiornato o Dopo <n> ore se <il nome del ramo> è stato aggiornato, lo stato del criterio si aggiorna quando il ramo protetto viene aggiornato, se la compilazione precedente non è più valida.

Controlli di stato

I servizi esterni possono utilizzare l'API Stato richieste di pull per pubblicare lo stato dettagliato delle vostre richieste di pull. La politica del ramo per i servizi aggiuntivi consente a tali servizi esterni di partecipare al flusso di lavoro PR e di stabilire i requisiti della politica.

Screenshot di Richiedi che i servizi esterni approvino.

Per istruzioni sulla configurazione di questo criterio, vedere Configurare un criterio di ramo per un servizio esterno.

Includi automaticamente revisori del codice

È possibile aggiungere automaticamente revisori alle richieste pull che modificano i file in directory e file specifici o a tutte le richieste pull in un repository.

  1. Selezionare il + pulsante accanto a Revisori inclusi automaticamente.

    Screenshot che mostra l'opzione Aggiungi revisori obbligatori.

  2. Compilare la schermata Aggiungi nuova politica revisore.

    Screenshot che mostra la schermata Aggiungi nuovi criteri di revisore.

    • Aggiungere utenti e gruppi ai revisori.

    • Selezionare Facoltativo se si desidera aggiungere automaticamente i revisori, ma non richiedere la loro approvazione per completare la pull request.

      In alternativa, selezionare Obbligatorio se le pull request non possono essere completate fino a quando:

      • Ogni utente aggiunto come revisore approva le modifiche.
      • Almeno una persona in ogni gruppo aggiunta come revisore approva le modifiche.
      • Se è necessario un solo gruppo, il numero minimo di membri specificati approva le modifiche.

    • Specificare i file e le cartelle che richiedono i revisori inclusi automaticamente. Lasciare vuoto questo campo per richiedere i revisori per tutte le pull request nel ramo.

    • Selezionare Consenti ai richiedenti di approvare le proprie modifiche se i proprietari delle richieste pull possono votare per approvare le proprie richieste pull per soddisfare questo criterio.

    • È possibile specificare un messaggio del feed attività che appare nella pull request.

  3. Seleziona Salva.

Ignorare i criteri delle branche

In alcuni casi, potrebbe essere necessario ignorare i requisiti dei criteri. Le autorizzazioni di bypass consentono di eseguire direttamente il push delle modifiche in un branch o di completare le richieste pull che non rispettano le politiche del branch. È possibile concedere autorizzazioni di bypass a un utente o a un gruppo. È possibile definire l'ambito delle autorizzazioni di bypass per un intero progetto, un repository o un singolo ramo.

Due autorizzazioni consentono agli utenti di ignorare i criteri di ramo in modi diversi:

  • Le regole di bypass per il completamento delle richieste pull si applicano solo al completamento della richiesta pull. Gli utenti con questa autorizzazione possono completare le richieste pull anche se le richieste pull non soddisfano i criteri.

  • Ignorare i criteri quando si esegue il push si applica ai push dai repository locali e alle modifiche apportate via Web. Gli utenti con questa autorizzazione possono eseguire il push delle modifiche direttamente nei rami protetti senza soddisfare i requisiti dei criteri.

Screenshot che mostra le autorizzazioni per l'applicazione delle politiche di bypass.

Per altre informazioni sulla gestione di queste autorizzazioni, vedere Autorizzazioni Git.

Importante

Prestare attenzione quando si concede la possibilità di ignorare i criteri, in particolare a livello di repository e progetto. I criteri sono un elemento fondamentale della gestione sicura e conforme del codice sorgente.

Filtri di percorso

Diverse politiche di ramo offrono filtri di percorso. Se viene impostato un filtro di percorso, il criterio si applica solo ai file che corrispondono al filtro del percorso. Lasciare vuoto questo campo significa che il criterio si applica a tutti i file nel ramo.

È possibile specificare percorsi assoluti (il percorso deve iniziare con / o con un carattere jolly) e caratteri jolly. Esempi:

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

È possibile specificare più percorsi usando ; come separatore. Esempio:

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

I percorsi preceduti ! da vengono esclusi se altrimenti verrebbero inclusi. Esempio:

  • /WebApp/*;!/WebApp/Tests/* include tutti i file in /WebApp ad eccezione dei file in /WebApp/Tests
  • !/WebApp/Tests/* non specifica alcun file, poiché non è incluso alcun elemento per primo

L'ordine dei filtri è significativo. I filtri vengono applicati da sinistra a destra.

Domande e risposte

Posso eseguire il push delle modifiche direttamente sulle branche che hanno politiche di ramo?

Non è possibile eseguire il push delle modifiche direttamente ai rami con i criteri di ramo richiesti, a meno che non si disponga delle autorizzazioni per ignorare i criteri dei rami. Le modifiche a questi rami possono essere apportate solo tramite richieste di pull. È possibile eseguire il push delle modifiche direttamente ai rami con criteri di ramo facoltativi , se non hanno criteri di ramo obbligatori.

Che cos'è il completamento automatico?

Le pull request nei rami con i criteri di ramo configurati hanno il pulsante Imposta completamento automatico. Selezionare questa opzione per completare automaticamente la richiesta pull dopo aver soddisfatto tutti i criteri. Il completamento automatico è utile quando non si prevedono problemi con le modifiche.

Quando vengono controllate le condizioni dei criteri della ramificazione?

Le politiche dei rami si rivalutano sul server quando i proprietari delle pull request applicano modifiche e quando i revisori votano. Se un criterio attiva una compilazione, lo stato della compilazione viene impostato su in attesa fino al completamento della compilazione.

È possibile usare le definizioni di compilazione XAML nei criteri di ramificazione?

No, non è possibile usare le definizioni di compilazione XAML nelle politiche di ramo.

Quali caratteri jolly è possibile usare per i revisori richiesti del codice?

Un singolo asterisco * corrisponde a un numero qualsiasi di caratteri, inclusi gli slash / e i backslash \. I punti interrogativi ? corrispondono a qualsiasi singolo carattere.

Esempi:

  • *.sql corrisponde a tutti i file con l'estensione .sql .
  • /ConsoleApplication/* corrisponde a tutti i file nella cartella denominata ConsoleApplication.
  • Il file /.gitattributes corrisponde al file di .gitattributes* nella radice del repository.
  • */.gitignore corrisponde a qualsiasi file .gitignore nel repo.

I percorsi dei revisori del codice necessari fanno distinzione tra maiuscole e minuscole?

No, le politiche dei rami non fanno distinzione tra maiuscole e minuscole.

Come è possibile configurare più utenti come revisori necessari, ma è necessario solo uno di essi per approvare?

È possibile aggiungere gli utenti a un gruppo e quindi aggiungere il gruppo come revisore. Qualsiasi membro del gruppo può quindi approvare per soddisfare i requisiti dei criteri.

Ho le autorizzazioni per i criteri di bypass. Perché vengono ancora visualizzati fallimenti dei criteri nello stato della pull request?

Le policy configurate vengono sempre valutate per le modifiche delle pull request. Per gli utenti che dispongono di autorizzazioni per bypassare le politiche, lo stato dei criteri segnalato è solo a scopo informativo. Se l'utente con autorizzazioni di bypass approva, lo stato di errore non blocca il completamento della richiesta pull.

Perché non posso completare le mie pull request quando è impostato "Consenti ai richiedenti di approvare le proprie modifiche"?

Sia il criterio Richiedi un numero minimo di revisori che il criterio Revisori inclusi automaticamente hanno le opzioni Consenti ai richiedenti di approvare le proprie modifiche. In ogni criterio, l'impostazione si applica solo a tale criterio. L'impostazione non influisce sugli altri criteri.

Ad esempio, per la richiesta pull sono impostati i criteri seguenti:

  • Richiedere un numero minimo di revisori richiede almeno un revisore.
  • I revisori inclusi automaticamente richiedono che l'utente o un team di cui si è parte siano assegnati come revisori.
  • I revisori inclusi automaticamente hanno Consenti ai richiedenti di approvare le proprie modifiche abilitato.
  • "Richiedere un numero minimo di revisori non ha Consenti ai richiedenti di approvare le proprie modifiche abilitato."

In questo caso, la tua approvazione soddisfa i revisori inclusi automaticamente, ma non Richiedi un numero minimo di revisori, quindi non è possibile completare la richiesta pull.

Potrebbero essere presenti anche altri criteri, ad esempio Impedisci al push più recente di approvare le proprie modifiche, che impediscono l'approvazione delle proprie modifiche anche se è impostata l'opzione Consenti ai richiedenti di approvare le proprie modifiche .

Cosa accade quando il percorso nei filtri di percorso non inizia con / o con un carattere speciale?

Il percorso nei filtri di percorso che non inizia con / o con un carattere jolly non ha alcun effetto, e il filtro di percorso viene valutato come se il percorso non fosse specificato. Un percorso di questo tipo non può corrispondere al percorso file assoluto che inizia con /.