Dela via

Grenprinciper och inställningar

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

Grenprinciper hjälper team att skydda sina viktiga utvecklingsgrenar . Policys upprätthåller ditt teams standarder för kodkvalitet och ändringshantering. I den här artikeln beskrivs hur du ställer in och hanterar grenprinciper. En översikt över alla principer och inställningar för lagringsplats och gren finns i Inställningar och principer för Git-lagringsplats.

En gren med nödvändiga principer som konfigurerats kan inte tas bort och kräver pull-begäranden (PR) för alla ändringar.

Förutsättningar

  • Om du vill ange grenprinciper måste du vara medlem i säkerhetsgruppen Projektadministratörer eller ha Redigera principer på lagringsplatsnivå behörigheter. Mer information finns i Ange Behörigheter för Git-lagringsplats.

  • Om du vill använda Azure DevOps CLI az repos policy-kommandon för att hantera grenprinciper följer du stegen i Kom igång med Azure DevOps CLI.

  • Om du vill ange grenprinciper måste du vara medlem i säkerhetsgruppen Projektadministratörer eller ha Redigera principer på lagringsplatsnivå behörigheter. Mer information finns i Ange Behörigheter för Git-lagringsplats.

Konfigurera grenprinciper

För att hantera grenprinciper väljer du Repos>Grenar för att öppna sidan Grenar i webbportalen.

Skärmbild som visar menyvalet Grenar.

Du kan också komma åt inställningarna för förgreningsprinciper med Projektinställningar>Arkiv>Principer>Förgreningsprinciper><Förgreningsnamn>.

Grenar som har policys visar en policyikon. Du kan välja ikonen för att gå direkt till grenens principinställningar.

Om du vill ange grenprinciper letar du upp den gren som du vill hantera. Du kan bläddra i listan eller söka efter din gren i rutan Sök grennamn uppe till höger.

Välj först ikonen Fler alternativ bredvid grenen, och välj sedan Grenpolicys från snabbmenyn.

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

Konfigurera principer på grenens inställningssida. Se följande avsnitt för beskrivningar och instruktioner för varje principtyp.

Kräv ett minsta antal granskare

Kodgranskningar är viktiga för programutvecklingsprojekt. För att säkerställa att team granskar och godkänner pr-begäranden kan du kräva godkännande från ett minsta antal granskare. Den grundläggande principen kräver att ett angivet antal granskare godkänner koden, utan avvisanden.

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

Sök efter 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.

Kontrollera kommentarers lösning

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

Konfigurera en policy för kommentarslösning för din gren genom att ställa in Kontrollera kommentarslösning till På. 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ärandekommentärer finns i Granska pull-begäranden.

Begränsa sammanslagningstyper

Azure Repos har flera sammanslagningsstrategier, och som standard tillåts alla. Du kan upprätthålla en konsekvent grenhistorik genom att framtvinga en sammanslagningsstrategi för slutförande av PR.

Ange Begränsa sammanslagningstyper till På för att begränsa vilka sammanslagningstyper som ska tillåtas 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.
  • Squash merge skapar en linjär historik med en enda commit i målgrenen med ä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.

Byggverifiering

Du kan ange en princip som kräver att PR-ändringar byggs framgångsrikt innan PR 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.

En byggvalideringsprincip köar en ny version när en ny PR skapas eller ändringar skickas till en befintlig PR som riktar sig mot grenen. Byggpolicyn utvärderar byggresultatet för att avgöra om PR:en kan fullbordas.

Viktigt!

Innan du anger en byggvalideringspolicy måste du ha en byggpipeline. 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.

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

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.

Anvisningar om hur du konfigurerar den här principen finns i Konfigurera en grenprincip för en extern tjänst.

Inkludera kodgranskare 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.

Kringgå grenprinciper

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. Du kan kringgå 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.

Sökvägsfilter

Flera grenprinciper erbjuder sökvägsfilter. Om ett sökvägsfilter har angetts gäller principen endast för filer som matchar sökvägsfiltret. Om du lämnar det här fältet tomt innebär det att principen gäller för alla filer i grenen.

Du kan ange absoluta sökvägar där sökvägen måste börja med antingen / eller ett jokertecken. Exempel:

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

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

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

Sökvägar som föregås av ! utesluts 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. Filter tillämpas från vänster till höger.

Frågor och svar

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. Ändringar i dessa grenar kan endast göras 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?

Pull-förfrågningar till grenar med konfigurerade grenprinciper har knappen Ange automatisk slutförande. Välj det här alternativet om du vill slutföra pull-begäran 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?

Grenprinciper omvärderas på servern när ägare av pull-requests överför ä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?

Enstaka asterisk * kan matcha valfritt antal tecken, inklusive både snedstreck / och bakåtsnedstreck \. 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?

Konfigurerade principer utvärderas alltid för ändringar i pull-begäran. 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-begäranden när "Tillåt begäranden att godkänna sina egna ändringar har angetts"?

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.

Det kan också finnas andra policyer, till exempel Förhindra att den senaste push-användaren godkänner sina egna ändringar, som hindrar dig från att godkänna dina egna ändringar även om Tillåt begärande användare att godkänna sina egna ändringar är inställd.

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

Sökvägen i sökvägsfilter som inte börjar med / eller med ett jokertecken har ingen effekt, och 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.