Ange och hantera grenprinciper

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Använd grenprinciper för att skydda viktiga grenar genom att kräva pull-begäranden, granskare, byggen och andra kontroller innan ändringarna slås samman. Den här artikeln visar hur du konfigurerar och hanterar grenprinciper i Azure DevOps webbportalen och Azure DevOps CLI. En sammanfattning av tillgängliga förgreningsprinciper och förgreningsvägledning finns i Om grenar och grenprinciper.

En omfattande säkerhetsguide som omfattar grenprinciper, åtkomstkontroll för lagringsplatser, incheckningssignering och verkliga implementeringsscenarier finns i Säkra lagringsplatser och pull-begäranden.

Du kan inte ta bort en gren med nödvändiga principer konfigurerade, och alla ändringar måste gå igenom pull-begäranden (PRs).

Tips/Råd

Du kan använda AI för att hjälpa till med den här uppgiften senare i den här artikeln, eller se Aktivera AI-hjälp med Azure DevOps MCP Server för att komma igång.

Förutsättningar

Requirement Detaljer
Permissions Var medlem i säkerhetsgruppen Project Administrators eller ha behörigheten Redigera principer på databassnivå. Mer information finns i Ange Behörigheter för Git-lagringsplats.
Azure DevOps CLI-installation (valfritt) Om du vill använda Azure DevOps CLI-kommandona az repos policy går du igenom Kom igång med Azure DevOps CLI.
Mål för lagringsplats för CLI (valfritt) Innan du skapar eller uppdaterar principer i CLI ska du identifiera lagringsplatsens ID genom att köra az repos list. För att undvika upprepande --org och --projectanger du standardvärden med az devops configure --defaults.
Policyberoenden Innan du konfigurerar buildverifiering bör du ha en byggpipeline klar. Innan du konfigurerar Statuskontroller kontrollerar du att den externa tjänsten eller den inbyggda integreringen redan kan publicera status för pull-begäran.
AI-hjälpkonfiguration (valfritt) Om du vill använda AI-hjälp med Azure DevOps MCP Server använder du Azure DevOps Services, aktiverar agentläge i AI-assistenten och installerar Node.js 20.0+. Mer information finns i Aktivera AI-hjälp med Azure DevOps MCP Server.
Requirement Detaljer
Permissions Var medlem i säkerhetsgruppen Project Administrators eller ha behörigheten Redigera principer på databassnivå. Mer information finns i Ange Behörigheter för Git-lagringsplats.

Öppna principinställningar för gren

Så här öppnar du inställningar för grenprinciper i webbportalen:

  1. Välj Repos>Brancher.
  2. Hitta den gren som du vill hantera.
  3. Välj ikonen Fler alternativ bredvid grenen och välj sedan Grenprinciper.

Skärmbild som visar menyvalet Grenar.

Du kan också öppna inställningarna för grenprinciper från Projektinställningar>Lagringsplats>Principer>Grenprinciper><Grennamn>.

Grenar som har policys visar en policyikon. Välj ikonen för att gå direkt till grenens principinställningar.

Du kan bläddra i listan eller söka efter grenen i rutan Sök grennamn .

Skärmbild som visar Öppna grenpolicyn från snabbmenyn.

Konfigurera principer på grenens inställningssida. Använd följande avsnitt för att aktivera eller uppdatera en befintlig princip.

Ange en princip för minsta granskare

Kräv godkännande från ett minsta antal granskare innan en pull-begäran kan slutföras.

Om du vill ange principen under Avdelningsprinciper anger du Kräv ett minsta antal granskare till På. Ange det antal granskare som krävs och välj något av följande alternativ:

Skärmbild som visar principen Aktivera principen Kräv kodgranskning.

  • Välj Tillåt begäranden att godkänna sina egna ändringar för att låta skaparen av en PR rösta på att godkänna den. Annars kan skaparen fortfarande rösta Godkänn på PR, men deras röst räknas inte mot det minsta antalet granskare.

  • Välj Förhindra att den senaste pusharen godkänner sina egna ändringar för att säkerställa ansvarsuppdelning. Som standardinställning kan alla som har push-behörighet på källgrenen både lägga till ändringar och rösta om godkännande av PR. Om du väljer det här alternativet räknas inte den senaste pusherns röst, även om de vanligtvis kan godkänna sina egna ändringar.

  • Välj Tillåt slutförande även om vissa granskare röstar för att vänta eller avvisa för att tillåta pr-slutförande även om vissa granskare röstar emot godkännande. Det minsta antalet granskare måste fortfarande godkänna.

  • Under När nya ändringar skickas:
    • Välj Kräv minst ett godkännande för varje iteration för att kräva minst en godkännanderöst för den senaste ändringen av källgrenen. Användarens godkännande räknas inte mot några tidigare icke godkända iterationer som användaren har pushat. Därför måste en annan användare godkänna den senaste iterationen. Kräv minst ett godkännande för varje iteration som är tillgänglig i Azure DevOps Server 2022.1 och senare.
    • Välj Kräv minst ett godkännande för den senaste iterationen för att kräva minst en godkännandeomröstning för den senaste ändringen av källgrenen.
    • Välj Återställ alla godkännanderöster (återställer inte röster för att avvisa eller vänta) för att ta bort alla godkännanderöster, men behåll röster för att avvisa eller vänta när källgrenen ändras.
    • Välj Återställ alla röster för kodgranskare för att ta bort alla granskarröster när källgrenen ändras, inklusive röster för att godkänna, avvisa eller vänta.

Om alla andra regler godkänns kan skaparen genomföra PR:n när det begärda antalet granskare godkänner den.

Kräv länkade arbetsobjekt

För spårning av arbetsobjektshantering kan du kräva associationer mellan pr och arbetsobjekt. Länkning av arbetsobjekt ger mer kontext för ändringar och säkerställer att uppdateringarna går igenom spårningsprocessen för arbetsobjekt.

Om du vill ange principen under Avdelningsprinciper anger du Sök efter länkade arbetsobjekt till På. Den här inställningen kräver att arbetsuppgifter är länkade till en PR för att PR:n ska kunna slås ihop. Gör inställningen Valfri för att varna när det inte finns några länkade arbetsobjekt, men tillåt slutförande av pull-begäran.

Skärmbild av krav på länkade arbetsobjekt i pull-begäranden.

Kräv att kommentarer löses

Policyn Check for comment resolution kontrollerar om alla PR-kommentarer har lösts.

Ställ in Kontrollera kommentarslösning på På för att konfigurera en policy för kommentarslösning för din gren. Välj sedan om du vill göra principen Obligatorisk eller Valfri.

Skärmbild av Kontrollera kommentarslösning.

Mer information om hur du arbetar med pull-begärandekommenteringar finns i Granska pull-begäranden.

Begränsa sammanslagningstyper

Azure-lagringsplatser stöder flera sammanslagningsstrategier, och som standard tillåter det alla. Om du vill behålla en konsekvent grenhistorik framtvingar du en sammanslagningsstrategi för slutförande av PR.

Ange Begränsa sammanslagningstyper till På för att begränsa vilka sammanslagningstyper som tillåts på lagringsplatsen.

Skärmbild av Begränsade sammanslagningstyper.

  • Grundläggande sammanslagning (ingen snabbsnabbning) skapar en sammanslagningsincheckning i målet vars överordnade objekt är mål- och källgrenarna.
  • Squashsammanslagning skapar en linjär historik med en enda incheckning i målgrenen som innehåller ändringarna från källgrenen. Läs mer om squashsammanslagningen och hur den påverkar grenhistoriken.
  • Ombasera och fast-forward skapar en linjär historik genom att spela upp källändringar på målgrenen utan sammanfogning.
  • Ombasera med sammanslagningsincheckning spelar upp källincheckningarna på målet och skapar även en sammanslagningsincheckning.

Ange byggverifiering

Ange en princip som kräver att PR-ändringar kan kompileras utan fel innan PR:n kan slutföras. Skapa principer minskar pauser och håller testresultaten klara. Byggprinciper hjälper även om du använder kontinuerlig integrering (CI) på dina utvecklingsgrenar för att fånga upp problem tidigt.

När du ställer in principutlösaren på Automatisk köar en princip för buildvalidering en ny build när du skapar en ny PR eller pushar ändringar till en befintlig PR som har grenen som mål. Om du anger utlösaren för principen till Manuell måste användarna själva lägga builden i kö. I båda fallen utvärderar policyn byggresultaten för att avgöra om en PR kan slutföras.

Viktigt!

Innan du anger en princip för byggverifiering skapar du en buildpipeline. Om du inte har någon pipeline, se Skapa en byggpipeline. Välj vilken typ av bygge som matchar din projekttyp.

Så här lägger du till en byggverifieringsprincip

  1. + Välj knappen bredvid Skapa validering.

    Skärmbild som visar knappen Lägg till bredvid Build-validering.

  2. Fyll i formuläret Ange byggprincip :

    Skärmbild av inställningar för byggpolicy.

    • Välj byggpipen.

  • Du kan också ange ett sökvägsfilter. Läs mer om sökvägsfilter i grenprinciper.

  • Under Utlösare väljer du Automatisk (när källgrenen uppdateras) eller Manuell.

  • Under Principkrav väljer du Obligatoriskt eller Valfritt. Om du väljer Obligatoriskt måste byggen slutföras framgångsrikt för att PR:er ska slutföras. Välj Valfritt om du vill ange ett meddelande om byggfelet men ändå tillåta att PR:er slutförs.

  • Ange ett byggdatum för att se till att uppdateringar av din skyddade gren inte bryter ändringar för öppna PR:er.

    • Omedelbart när <grennamnet> uppdateras: Det här alternativet anger status för PR-byggprincipen till misslyckad när grenen uppdateras och returnerar en version på nytt. Den här inställningen säkerställer att ändringarna i PR:en byggs framgångsrikt även om den skyddade grenen ändras.

      Det här alternativet passar bäst för team vars viktiga grenar har få ändringar. Team som arbetar i upptagna utvecklingsgrenar kan tycka att det är störande att vänta på ett bygge varje gång grenen uppdateras.

    • Efter <n> timmar om <grennamnet> har uppdaterats: Det här alternativet upphör att gälla den aktuella principstatusen när den skyddade grenen uppdateras om den övergående versionen är äldre än det tröskelvärde som du anger. Det här alternativet är en kompromiss mellan att alltid eller aldrig kräva en build när den skyddade grenen uppdateras. Det här valet minskar antalet versioner när den skyddade grenen har frekventa uppdateringar.

    • Aldrig: Uppdateringar av den skyddade grenen ändrar inte principstatusen. Det här värdet minskar antalet kompileringar, men kan orsaka problem när du fullföljer PR:ar som inte har uppdaterats nyligen.

  • Ange ett valfritt visningsnamn för den här byggprincipen. Det här namnet identifierar policyn på sidan Grenprinciper. Om du inte anger visningsnamn använder principen namnet på byggpipeline.

  1. Välj Spara.

När PR-owner pushar ändringar som kompileras framgångsrikt, uppdateras statusen för policyn.

Om du har en Så snart <grennamnet> uppdateras eller Efter <n> timmar om <grennamnet> har uppdaterats, uppdateras statusen för policyn när den skyddade grenen uppdateras, om den tidigare kompileringsversionen inte längre är giltig.

Kräv statuskontroller

Externa tjänster kan använda PR-status-API:et för att publicera detaljerad status till dina pr-flöden. Med grenprincipen för ytterligare tjänster kan dessa externa tjänster delta i PR-arbetsflödet och upprätta principkrav.

Skärmbild av Kräv att externa tjänster godkänns.

Så här konfigurerar du en princip för statuskontroll:

  1. Kontrollera att tjänsten kan rapportera status för pull requests till Azure-lagringsplatser.
  2. Under Statuskontroller i Grenprinciper väljer du +.
  3. I Kontrollstatus väljer du den bokförda checken i listan. Om tjänsten inte har bokfört status ännu skriver du värdet genre/name direkt.
  4. Ange Principkrav tillObligatoriskt eller Valfritt.
  5. Du kan också konfigurera auktoriserad identitet, återställningsvillkor, principanvändning och sökvägsfilter.
    • Använd Använd som standard om principen ska tillämpas så snart pull-begäran har skapats.
    • Använd Villkorsstyrd om principen endast ska gälla när den första statusen har bokförts.
  6. Skapa eller uppdatera en pull request som är riktad mot grenen och bekräfta att policyn visas i avsnittet Policies.

För inbyggda Azure DevOps Services-kontroller och deras genre/name identifierare, se Tillgängliga statuskontroller för pull-begäranden. En fullständig genomgång av konfigurationen av externa tjänster finns i Konfigurera en grenprincip för en extern tjänst.

Om en ny integrering inte visas i listrutan än, skickar du status en gång från tjänsten och lägger sedan till policyn, eller skriver värdet genre/name direkt.

Inkludera granskare automatiskt

Du kan automatiskt lägga till granskare till pull-begäranden som ändrar filer i specifika kataloger och filer, eller till alla pull-begäranden på en lagringsplats.

  1. + Välj knappen bredvid Automatiskt inkluderade granskare.

    Skärmbild som visar Lägg till nödvändiga granskare.

  2. Fyll i sidan Lägg till ny granskarpolicy.

    Skärmbild som visar fönstret Lägg till ny granskarpolicy.

    • Lägg till personer och grupper i Granskare.

    • Välj Valfritt om du vill lägga till granskare automatiskt, men inte kräva deras godkännande för att slutföra pull-begäran.

      Eller välj Obligatoriskt om pull-begäranden inte kan slutföras förrän:

      • Varje individ som läggs till som granskare godkänner ändringarna.
      • Minst en person i varje grupp som läggs till som granskare godkänner ändringarna.
      • Om endast en grupp krävs godkänner det minsta antalet medlemmar som du anger ändringarna.

    • Ange de filer och mappar som kräver automatiskt inkluderade granskare. Lämna fältet tomt för att kräva granskare för alla pull-förfrågningar i grenen.

    • Välj Tillåt användare att godkänna sina egna ändringar om ägarna av pull-begäranden kan rösta för att godkänna sina egna pull-begäranden för att uppfylla denna policy.

    • Du kan ange ett aktivitetsflödesmeddelande som visas i pull-begäran.

  3. Välj Spara.

Tillåt kringgående av policy vid behov

I vissa fall kan du behöva kringgå principkraven. Med förbikopplingsbehörigheter kan du skicka ändringar till en gren direkt eller slutföra pull-begäranden som inte uppfyller grenprinciper. Du kan bevilja förbikopplingsbehörigheter till en användare eller grupp och omfångsbegränsa dessa behörigheter till ett helt projekt, en lagringsplats eller en enda gren.

Med två behörigheter kan användare kringgå grenprinciper på olika sätt:

  • Kringgå principer när du slutför pull-begäranden gäller endast för slutförande av pull-begäranden. Användare med den här behörigheten kan slutföra pull-begäranden även om pull-begäranden inte uppfyller principerna.

  • Kringgå principer vid push-överföring gäller push-överföring från lokala lagringsplatser och ändringar som görs på webben. Användare med den här behörigheten kan skicka ändringar direkt till skyddade grenar utan att uppfylla principkraven.

Skärmbild som visar behörigheter för att kringgå principtillämpning.

Mer information om hur du hanterar dessa behörigheter finns i Git-behörigheter.

Viktigt!

Var försiktig när du ger möjlighet att kringgå principer, särskilt på lagringsplats- och projektnivå. Principer är en hörnsten i säker och kompatibel källkodshantering.

Använd sökvägsfilter med grenpolicyer

Flera grenprinciper stöder sökvägsfilter. Om du anger ett sökvägsfilter gäller principen endast för filer som matchar filtret. Lämna fältet tomt för att tillämpa principen på alla filer i grenen.

Du kan ange absoluta sökvägar (sökvägen måste börja med / eller ett jokertecken) och jokertecken. Exempel:

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

Du kan ange flera sökvägar med hjälp ; av som avgränsare. Exempel:

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

Om du lägger till prefixet ! före sökvägar utesluter du dem om de annars skulle inkluderas. Exempel:

  • /WebApp/*;!/WebApp/Tests/* innehåller alla filer i /WebApp utom filer i /WebApp/Tests
  • !/WebApp/Tests/* anger inga filer, eftersom ingenting inkluderas först

Filterordningen är betydande. Använd filter från vänster till höger.

Felsöka grenprinciper

Kan jag skicka ändringar direkt till grenar som har grenprinciper?

Du kan inte push-överföra ändringar direkt till grenar med nödvändiga grenprinciper om du inte har behörighet att kringgå grenprinciper. Du kan bara göra ändringar i dessa grenar via pull-begäranden. Du kan skicka ändringar direkt till grenar som har valfria grenprinciper, om de inte har några nödvändiga grenprinciper.

Vad är automatisk komplettering?

Grenar med grensprinciper som har konfigurerats för pullbegäranden har knappen Ange automatiskt slutförande. Välj det här alternativet om du vill ange att en pull-begäran ska kompletteras automatiskt när den uppfyller alla principer. Automatisk komplettering är användbart när du inte förväntar dig några problem med dina ändringar.

När kontrolleras villkor för grenkriterier?

Servern omvärderar grenpolicyer när ägare av pull requests pushar ändringar och när granskare röstar. Om en regel utlöser en kompilering ställs kompileringsstatusen i vänteläge tills kompileringen har slutförts.

Kan jag använda XAML-versionsdefinitioner i grenprinciper?

Nej, du kan inte använda XAML-byggdefinitioner i grenprinciper.

Vilka jokertecken kan jag använda för obligatoriska kodgranskare?

Enkla asterisker * matchar ett valfritt antal tecken, inklusive både vanliga snedstreck / och omvända snedstreck \. Frågetecken ? motsvarar ett enskilt tecken.

Exempel:

  • *.sql matchar alla filer med tillägget .sql .
  • /ConsoleApplication/* matchar alla filer i mappen som heter ConsoleApplication.
  • /.gitattributes motsvarar filen.gitattributes* i rotmappen i lagringsplatsen.
  • */.gitignore matchar alla .gitignore-filer i repot.

Är kodgranskarens nödvändiga sökvägar skiftlägeskänsliga?

Nej, grenprinciper är inte skiftlägeskänsliga.

Hur konfigurerar jag flera användare som nödvändiga granskare, men behöver bara en av dem för att godkänna?

Du kan lägga till användarna i en grupp och sedan lägga till gruppen som granskare. Alla medlemmar i gruppen kan sedan godkänna för att uppfylla principkravet.

Jag har behörighet att kringgå principer. Varför ser jag fortfarande policyfel i pull request-statusen?

Systemet utvärderar alltid konfigurerade principer för pull-begärandeändringar. För användare som har behörighet att kringgå principer är den rapporterade principstatusen endast rådgivande. Om användaren med särskilda behörigheter godkänner, blockeras inte pull-förfrågans slutförande av ett misslyckandestatus.

Varför kan jag inte slutföra mina egna pull requests när jag anger "Tillåt att den som skapar begäran godkänner sina egna ändringar"?

Både principen Kräv ett minsta antal granskare och principen Automatiskt inkluderade granskare har alternativ för att tillåta begärande att godkänna sina egna ändringar. I varje policy gäller inställningen endast för den policyn. Inställningen påverkar inte den andra principen.

Din pull-begäran har till exempel följande principer inställda:

  • Kräv minst ett antal granskare kräver minst en granskare.
  • Automatiskt inkluderade granskare kräver att du eller ett team du är i fungerar som en granskare.
  • Automatiskt inkluderade granskare har Tillåt begäranden att godkänna sina egna ändringar aktiverade.
  • Kräv ett minsta antal granskare har inte Tillåt begäranden att godkänna sina egna ändringar aktiverat.

I det här fallet uppfyller ditt godkännande automatiskt inkluderade granskare, men inte Kräv ett minsta antal granskare, så du kan inte slutföra pull-begäran.

Andra principer kan hindra dig från att godkänna dina egna ändringar, även om Tillåt begäranden att godkänna sina egna ändringar har angetts. Till exempel förhindra att den som senast pushade godkänner sina egna ändringar.

Vad händer när ett sökvägsfilter inte börjar med / eller ett jokertecken?

En sökväg i sökvägsfilter som inte börjar med / eller med ett jokertecken har ingen effekt. Sökvägsfiltret utvärderas som om sökvägen inte angavs. En sådan sökväg kan inte matcha den absoluta filsökväg / som den börjar med.

Använda AI för att konfigurera och hantera grenprinciper

Om du konfigurerar Azure DevOps MCP-server kan du använda naturligt språk för att samla in lagringsplats, gren, pull-begäran och skapa kontext innan du uppdaterar grenprinciper i Azure DevOps Services.

AZURE DEVOPS MCP-servern kräver Azure DevOps Services, agentläge i AI-assistenten och Node.js 20.0+. Den aktuella MCP-dokumentationen beskriver inte direkt läs- eller skrivåtgärder för grenprinciper, så använd Azure DevOps webbportalen eller Azure DevOps CLI för att skapa och uppdatera principer.

Uppgift Exempelprompt
Visa en lista över grenar på en lagringsplats List the branches in repo <Contoso.Web> in project <Contoso>
Granska pullförfrågningar innan du skärper policyn What pull requests require my review in project <Contoso>?
Granska en pullbegäran och länkade arbetsobjekt Get details for pull request <67> and its linked work items in project <Contoso>
Kontrollera byggstatusen innan du gör byggverifieringen obligatorisk Get the latest build status for pipeline <Contoso-CI> in project <Contoso>

Note

Om du använder Visual Studio Code är agentläget särskilt användbart för att samla in den projektkontext du behöver innan du uppdaterar grenprinciper.

Relaterat innehåll

  • Last updated on