Öva på Azure Repos i samarbete med pull-begäranden
Kodproblem som hittas tidigare är både enklare och billigare att åtgärda. Utvecklingsteamen strävar därför efter att skicka kodkvalitetskontroller så långt till vänster i utvecklingsprocessen som möjligt.
Som namnet antyder ger grenpolicyer dig en uppsättning fördefinierade policyer som kan tillämpas på grenarna på servern.
Ändringar som skickas till servergrenarna måste följa dessa principer innan ändringarna kan accepteras.
Principer är ett bra sätt att framtvinga teamets standarder för kodkvalitet och ändringshantering. I det här receptet får du lära dig hur du konfigurerar grenprinciper på huvudgrenen.
Gör dig redo
De färdiga grenprinciperna innehåller flera principer, till exempel byggvalidering och framtvinga en sammanslagningsstrategi. Vi fokuserar bara på de grenprinciper som behövs för att konfigurera ett arbetsflöde för kodgranskning i det här receptet.
Så här gör du det
Öppna grenvyn för Git-lagringsplatsen myWebApp i Parts Unlimited teamportalen. Välj huvudgrenen, och från den nedrullningsbara kontextmenyn, välj Grenprinciper.
I policyvy visar den fördefinierade policyer. Ange det minsta antalet granskare till 1:
Alternativet Tillåt begäranden att godkänna sina egna ändringar gör det möjligt för inskickare att godkänna ändringarna själv.
Även om detta kan vara acceptabelt för mogna team bör det i allmänhet undvikas.
Använd granskningsprincipen med kommentarslösningsprincipen. Det gör att du kan framtvinga att kodgranskningskommentarna löses innan ändringarna godkänns. Beställaren kan ta feedback från kommentaren och skapa ett nytt arbetsobjekt och lösa ändringarna. Det garanterar åtminstone att kommentarer för kodgranskning inte går förlorade när koden accepteras i huvudgrenen:
Ett krav initierar en kodändring i teamprojektet. Om arbetsobjektet som utlöste arbetet inte är länkat till ändringen blir det svårt att förstå varför det gjordes över tid. Det är särskilt användbart när du granskar historiken för ändringar. Konfigurera principen Sök efter länkade arbetsobjekt för att blockera ändringar som inte har ett arbetsobjekt länkat till dem:
Välj alternativet för att automatiskt inkludera granskare när en pull-begäran genereras automatiskt. Du kan mappa vilka granskare som läggs till baserat på det område i koden som ändras:
Så här fungerar det
När grenprinciperna är på plats är huvudgrenen nu helt skyddad.
Det enda sättet att pusha ändringar till huvudgrenen är att först göra ändringarna i en annan gren och sedan skapa en pull-begäran för att utlösa godkännandearbetsflödet.
Välj att skapa en ny gren från en av de befintliga användarberättelserna i arbetsobjekthubben.
Genom att skapa en ny gren från ett arbetsobjekt länkas arbetsobjektet automatiskt till grenen.
Du kan också inkludera fler än ett arbetsobjekt med en gren som en del av skapa-arbetsflödet.
Prefix i namnet när du skapar grenen för att skapa en mapp för grenen att gå in i.
I föregående exempel hamnar grenen i mappen . Det är ett bra sätt att organisera grenar i livliga miljöer.
När den nyligen skapade grenen har valts i webbportalen redigerar du HomeController.cs-filen så att den innehåller följande kodfragment och checkar in ändringarna i grenen.
I bilden nedan ser du att du kan checka in ändringarna direkt när du har redigerat filen genom att klicka på incheckningsknappen.
Filsökvägskontrollen i teamportalen stöder sökning.
Börja skriva filsökvägen för att se alla filer i din Git-lagringsplats under den katalogen. Bokstäverna du skriver visas i rullgardinslistan med sökresultaten för sökvägen.
Kodredigeraren i webbportalen har flera nya funktioner i Azure DevOps Server, till exempel stöd för matchning av parenteser och växla visning av blanksteg.
Du kan läsa in kommandopaletten genom att trycka på den. Bland många andra nya alternativ kan du nu växla filen med hjälp av en minikarta, komprimera och expandera och andra standardåtgärder.
För att skicka ändringarna från den nya grenen till huvudgrenen, skapa en pullförfrågan från pullförfrågevyn.
Välj den nya grenen som källgren och huvudgrenen som målgren.
Det nya formuläret för pull-begäran stöder markdown, så du kan lägga till beskrivningen med hjälp av markdown-syntaxen.
Beskrivningsfönstret stöder även @ omnämnanden och # för att länka arbetsobjekt:
Pull-begäran har skapats; översiktssidan sammanfattar ändringarna och statusen för policyn.
På fliken Filer visas en lista över ändringar och skillnaden mellan de tidigare och de aktuella versionerna.
Alla uppdateringar som skickas till kodfilerna visas på fliken Uppdateringar och en lista över alla incheckningar visas under fliken Incheckningar:
Öppna fliken Filer: den här vyn stöder kodkommentarer på radnivå, filnivå och övergripande.
Kommentarerna stöder både @ för omnämnanden och # för att länka arbetsobjekt, och texten stöder markdown-syntax:
Kodkommentarna sparas i arbetsflödet för pull-begäran. kodkommentarerna stöder flera iterationer av granskningar och fungerar bra med kapslade svar.
Granskningsprincipen tillåter ett arbetsflöde för kodgranskning som en del av godkännandet av ändringen.
Det är ett utmärkt sätt för teamet att samarbeta om eventuella kodändringar som skickas till huvudgrenen.
När det nödvändiga antalet granskare godkänner pull-begäran kan den slutföras.
Du kan också markera pull-begäran om att komplettera automatiskt efter granskningen. Automatiskt kompletteras pull-begäranden när alla regler har kompilerats.
Det finns mer
Har du någonsin varit i ett tillstånd där en gren har tagits bort av misstag? Det kan inte vara lätt att ta reda på vad som hände.
Azure DevOps Server stöder nu sökning efter borttagna grenar. Det hjälper dig att förstå vem som tog bort den och när. Med gränssnittet kan du också återskapa grenen.
Borttagna grenar visas bara om du söker efter dem med deras exakta namn för att minska bruset från sökresultaten.
Om du vill söka efter en borttagen gren anger du det fullständiga grennamnet i sökrutan för grenen. Den returnerar alla befintliga grenar som matchar texten.
Du ser också ett alternativ för att söka efter en exakt matchning i listan över borttagna grenar.
Om en matchning hittas ser du vem som tog bort den och när. Du kan också återställa grenen. Om du återställer grenen kommer den att återskapas vid det commit som den senast pekade på.
Den återställer dock inte principer och behörigheter.