Impostare e gestire i criteri dei rami

servizi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Usa i criteri dei branch per proteggere i branch importanti imponendo pull request, revisori, build e altri controlli prima dell'unione delle modifiche. Questo articolo illustra come configurare e gestire i criteri dei rami nel portale Web Azure DevOps e nell'interfaccia della riga di comando di Azure DevOps. Per un riepilogo dei criteri dei rami disponibili e delle linee guida per la diramazione, vedere Informazioni sui rami e i criteri dei rami.

Per una guida completa alla sicurezza relativa ai criteri dei rami, al controllo di accesso del repository, alla firma del commit e agli scenari di implementazione reali, vedere Proteggere i repository e le richieste pull.

Non è possibile eliminare un ramo con policy obbligatorie configurate e tutte le modifiche devono essere apportate tramite richieste pull (PR).

Suggerimento

È possibile usare l'intelligenza artificiale per facilitare questa attività più avanti in questo articolo, oppure vedere Abilitare l'assistenza AI con Azure DevOps MCP Server per iniziare.

Prerequisiti

Requirement dettagli
Permissions Essere membri del gruppo di sicurezza Project Administrators o disporre delle autorizzazioni di modifica a livello di repository. Per altre informazioni, vedere Impostare le autorizzazioni del repository Git.
Configurazione di Azure DevOps CLI (facoltativo) Per usare i comandi az repos policy dell'interfaccia della riga di comando di Azure DevOps, completare Introduzione all'interfaccia della riga di comando di Azure DevOps.
Selezione del repository per la CLI (facoltativo) Prima di creare o aggiornare i criteri nell'interfaccia della riga di comando, identificare l'ID del repository eseguendo az repos list. Per evitare di ripetere --org e --project, imposta i valori predefiniti con az devops configure --defaults.
Dipendenze dei criteri Prima di configurare la convalida della compilazione, assicurarsi di avere una pipeline di compilazione già pronta. Prima di configurare i controlli di stato, assicurarsi che il servizio esterno o l'integrazione predefinita possa già registrare lo stato della richiesta pull.
Configurazione dell'assistenza di intelligenza artificiale (facoltativo) Per usare l'assistenza di intelligenza artificiale con Azure DevOps SERVER MCP, usare Azure DevOps Services, abilitare la modalità agente nell'assistente per intelligenza artificiale e installare Node.js 20.0+. Per altre informazioni, vedere Abilitare l'assistenza di intelligenza artificiale con Azure DevOps server MCP.
Requirement dettagli
Permissions Essere membri del gruppo di sicurezza Project Administrators o disporre delle autorizzazioni di modifica a livello di repository. Per altre informazioni, vedere Impostare le autorizzazioni del repository Git.

Apri le impostazioni dei criteri del branch

Per aprire le impostazioni dei criteri del branch nel portale Web:

  1. Selezionare Repository>Rami.
  2. Trovare il ramo che si vuole gestire.
  3. Selezionare l'icona Altre opzioni accanto al ramo e quindi selezionare Criteri di ramo.

Screenshot che mostra la voce di menu Filiali.

È anche possibile aprire le impostazioni dei criteri del ramo da Impostazioni progetto>Repository>Criteri>Criteri del ramo><Nome del ramo>.

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

È possibile esplorare l'elenco o cercare il ramo nella casella Nome ramo di ricerca .

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

Configurare i criteri nella pagina delle impostazioni del ramo. Utilizzare le sezioni seguenti per attivare ciascun criterio o aggiornare un criterio esistente.

Imposta un criterio minimo per i revisori

Richiedere l'approvazione da un numero minimo di revisori prima che una richiesta pull possa essere completata.

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. Altrimenti, il creatore può comunque esprimere un voto di Approva sulla PR, ma il suo voto non viene conteggiato ai fini del 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 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.

Richiedere 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.

Richiedere la risoluzione dei commenti

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

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

Screenshot di Verifica della risoluzione dei commenti.

Per altre informazioni sull'uso dei commenti delle richieste pull, vedere Esaminare le richieste pull.

Limitare i tipi di unione

Azure Repos supporta diverse strategie di merge e, per impostazione predefinita, consente tutte le strategie. Per mantenere una cronologia dei rami coerente, imporre una strategia di merge per il completamento delle pull request.

Impostare Limita tipi di unione su Sì per limitare i tipi di merge consentiti 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.
  • L'unione di squash crea una cronologia lineare con un singolo commit nel ramo di destinazione che include le modifiche dal 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.

Impostare la convalida della compilazione

Impostare un criterio che richiede che le modifiche della PR vengano compilate correttamente prima che la PR possa essere completata. 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.

Quando si imposta il trigger dei criteri su Automatico, un criterio di convalida della compilazione accoda una nuova compilazione quando si crea una nuova richiesta pull o si esegue il push delle modifiche a una richiesta pull esistente destinata al ramo. Se si imposta il trigger del criterio su Manual, gli utenti devono mettere in coda la build manualmente. In entrambi i casi, la policy valuta i risultati della compilazione per determinare se la pull request può essere completata.

Importante

Prima di specificare un criterio di convalida della compilazione, creare 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.

  1. 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.

Richiedi 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 configurare un criterio di controllo dello stato:

  1. Assicurarsi che il servizio possa pubblicare lo stato della pull request in Azure Repos.
  2. In Criteri di ramo, in Controlli di stato selezionare +.
  3. In Stato da controllare selezionare il controllo pubblicato nell'elenco. Se il servizio non ha ancora pubblicato uno stato, digita direttamente il valore genre/name.
  4. Impostare Il requisito dei criteri su Obbligatorio o Facoltativo.
  5. Facoltativamente, configura identità autorizzata, condizioni di reimpostazione, applicabilità dei criteri e filtro del percorso.
    • Usare Applica per impostazione predefinita se il criterio deve essere applicato non appena viene creata la richiesta pull.
    • Usare Condizionale se il criterio deve essere applicato solo dopo la pubblicazione del primo stato.
  6. Creare o aggiornare una richiesta pull destinata al ramo e verificare che i criteri siano visualizzati nella sezione Criteri della richiesta pull.

Per i controlli predefiniti dei servizi di Azure DevOps e i relativi genre/name identificatori, vedere Controlli di stato delle richieste pull disponibili. Per una guida completa alla configurazione di un servizio esterno, vedi Configurare un criterio del ramo per un servizio esterno.

Se una nuova integrazione non viene ancora visualizzata nell'elenco a discesa, pubblicare lo stato una volta dal servizio e quindi aggiungere il criterio, oppure digitare direttamente il valore genre/name.

Includere automaticamente i revisori

È 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.

Consenti di ignorare i criteri quando necessario

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 e definire l'ambito di tali autorizzazioni 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.

Usare i filtri di percorso con i criteri di ramo

Alcuni criteri del ramo supportano i filtri di percorso. Se si imposta un filtro di percorso, il criterio si applica solo ai file che corrispondono al filtro. Lascia vuoto questo campo per applicare il criterio 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

Se anteponi ! ai percorsi, li escludi se altrimenti sarebbero 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. Applicare filtri da sinistra a destra.

Risolvere i problemi relativi ai criteri del ramo

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. È possibile apportare modifiche solo a questi rami tramite richieste 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?

I rami per cui sono configurati criteri del ramo per le pull request hanno il pulsante Attiva completamento automatico. Selezionare questa opzione per impostare una richiesta pull per il completamento automatico una volta soddisfatti tutti i criteri. Il completamento automatico è utile quando non si prevedono problemi con le modifiche.

Quando vengono controllate le condizioni dei criteri della ramificazione?

Il server rivaluta i criteri di ramo quando gli autori delle pull request inviano 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?

Gli asterischi singoli * corrispondono a un numero qualsiasi di caratteri, inclusi sia gli slash / sia 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 visualizzati ancora errori dei criteri nello stato della richiesta pull?

Il sistema valuta sempre i criteri configurati per le modifiche delle richieste pull. Per gli utenti che dispongono di autorizzazioni per ignorare i criteri, lo stato dei criteri segnalato è solo consultivo. Se l'utente con autorizzazioni di bypass approva, lo stato di errore non blocca il completamento della richiesta pull.

Perché non è possibile completare le richieste pull quando si imposta "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.

Altri criteri potrebbero impedire l'approvazione delle proprie modifiche, anche se è impostata l'opzione Consenti ai richiedenti di approvare le proprie modifiche . Ad esempio, Impedisci al pusher più recente di approvare le proprie modifiche.

Cosa accade quando un filtro di percorso non inizia con / o con un carattere jolly?

Un percorso nei filtri del percorso che non inizia con / o con un wildcard non ha alcun effetto. Il filtro di percorso restituisce come se tale percorso non fosse specificato. Un percorso di questo tipo non può corrispondere al percorso file assoluto che inizia con /.

Usare l'intelligenza artificiale per configurare e gestire i criteri dei rami

Se si configura il server MCP Azure DevOps, è possibile usare il linguaggio naturale per raccogliere repository, ramo, richiesta pull e contesto di compilazione prima di aggiornare i criteri dei rami in Azure DevOps Services.

Il server MCP Azure DevOps richiede Azure DevOps Services, la modalità agente nell'assistente intelligenza artificiale e Node.js 20.0+. La documentazione attuale di MCP non descrive operazioni dirette di lettura o scrittura dei criteri dei rami, quindi usa il portale Web di Azure DevOps o la CLI di Azure DevOps per creare e aggiornare i criteri.

Attività Richiesta di esempio
Elencare i rami del repository List the branches in repo <Contoso.Web> in project <Contoso>
Esaminare le pull request prima di inasprire i criteri What pull requests require my review in project <Contoso>?
Esamina una pull request e gli elementi di lavoro collegati Get details for pull request <67> and its linked work items in project <Contoso>
Controllare lo stato della compilazione prima di rendere necessaria la convalida della compilazione Get the latest build status for pipeline <Contoso-CI> in project <Contoso>

Annotazioni

Se si usa Visual Studio Code, la modalità agente è particolarmente utile per raccogliere il contesto del progetto necessario prima di aggiornare i criteri dei rami.

Contenuti correlati

  • Last updated on