Granska och sammanfoga Bicep-ändringar
Du har lärt dig hur du använder funktionsgrenar och hur du tillämpar grenskydd för att säkerställa att ändringar granskas innan de sammanfogas. Nu måste du följa en konsekvent process för att föreslå och granska dina ändringar innan de slås samman.
I den här lektionen får du lära dig mer om pull-begäranden, inklusive hur du skapar och använder dem. Du får också lära dig hur du kan använda pull-begäranden för att granska Bicep-kod.
Pull-begäranden
En pull-förfrågan är en förfrågan från dig som har utvecklat en funktion, till underhållaren av huvudgrenen. Du ber underhållaren att hämta ändringarna till huvudgrenen på lagringsplatsen.
Pull-begäranden och grenskydd
När du konfigurerar grenskydd kan du kräva att kodägarna granskar pull-begäran. Du kan till exempel inkludera projektledare som granskare för alla dina pull-förfrågningar, eller så kan du ange att ett visst antal personer måste granska varje pull-förfrågan.
Pull-begäranden och grenpolicyer
När du konfigurerar grenprinciper kan du kräva att specifika personer eller en grupp personer granskar pull-begäran. Du kan till exempel inkludera projektledare som granskare för alla dina pull-förfrågningar, eller så kan du ange att ett visst antal personer måste granska varje pull-förfrågan.
Du kan också kräva att varje pull-begäran är länkad till ett arbetsobjekt. Med den här konfigurationen kan du spåra från ett arbetsobjekt som innehåller en funktionsbegäran till koden som implementerar ändringen, hela vägen till distributionen till produktionsmiljön.
Skapa en pull-begäran
Du kan skapa en pull-begäran med hjälp av GitHub-webbgränssnittet. Du väljer källgrenen, där du har gjort dina ändringar, och målgrenen, som vanligtvis är lagringsplatsens huvudgren.
Du kan skapa en pull-begäran med hjälp av Azure DevOps-webbgränssnittet. Du väljer källgrenen, där du har gjort dina ändringar, och målgrenen, som vanligtvis är lagringsplatsens huvudgren.
När du skapar en pull-begäran måste du ge den ett namn. Det är en bra idé att göra pull-begärandens namn tydliga och begripliga. Den här metoden hjälper dina teammedlemmar att förstå kontexten för vad de uppmanas att granska. Om de har olika expertområden kan ett bra namn hjälpa dem att hitta pull-begäranden där de kan bidra med meningsfull feedback och hoppa över pull-begäranden som inte är relevanta.
Namn på pull-begäranden blir ofta en del av din Git-lagringsplatss historik, så det är en bra idé att göra dem begripliga när någon tittar tillbaka på historiken.
Du kan också ge pull-begäranden en beskrivning. Du kan nämna specifika personer eller referera till problem i dina beskrivningar. Många team skapar standardiserade mallar för beskrivningar av pull-begäranden så att det är tydligt vad varje ändring är.
Du kan också ge pull-begäranden en beskrivning. Du kan nämna specifika personer eller referera till arbetsobjekt i dina beskrivningar. Många team skapar standardiserade mallar för beskrivningar av pull-begäranden så att det är tydligt vad varje ändring är.
När du skapar en pull-begäran kan du bjuda in personer att granska ändringarna.
Ibland skapar du en pull-begäran bara för att få feedback från dina kollegor. I dessa situationer kan du ange att pull-begäran är ett utkast. Granskare vet att du fortfarande arbetar med ändringarna. Granskarna kan fortfarande ge feedback, men det är tydligt att ändringarna inte är redo att slås samman ännu. När du är nöjd med ändringarna kan du ta bort utkaststatusen.
Även när du har skapat en pull request kan du fortsätta att göra ändringar i koden på din feature branch. Dessa ändringar blir en del av pull-begäran.
Granska en pull-begäran
När du granskar en pull-förfrågan kan du se alla ändringar. Du kan kommentera hela pull-begäran eller bara på specifika delar av filerna som har ändrats. Pull-begärandeförfattaren kan svara på kommentarer och andra granskare kan delta i diskussioner. De här kommentarsfunktionerna gör samarbete vid pull-begäranden till en interaktiv upplevelse.
När du granskar Bicep-kod letar du efter följande nyckelelement:
- Kan filen distribueras? Distribuera och testa Bicep-koden innan den sammanfogas. Se till att det inte finns några lintervarningar och att Azure-distributionen lyckas. I en framtida Microsoft Learn-modul får du lära dig mer om metoder för att automatiskt distribuera och verifiera dina ändringar.
- Är Bicep-koden tydlig och begriplig? Det är viktigt att alla i ditt team förstår din Bicep-kod. När du granskar en Bicep-fil i en pull-begäran kontrollerar du att du förstår exakt vad varje ändring är till för. Är variabler och parametrar väl namngivna? Har kommentarer använts för att förklara några komplexa kodavsnitt?
- Är ändringen klar? Om den här pull-begäran är en del av ett större arbete, säkerställ att din miljö kommer att fungera när ändringen sammanförs och tas i bruk. Om pull-begäran till exempel konfigurerar om en Azure-resurs som förberedelse för en senare ändring kontrollerar du att resursen fortsätter att fungera korrekt under hela processen. Om pull-begäran lägger till en ny Azure-resurs som inte behövs ännu bör du överväga om ett villkor ska läggas till tillfälligt så att resursen inte distribueras förrän den behövs.
- Följer ändringen goda metoder inom Bicep? I andra Microsoft Learn-moduler har du lärt dig om elementen i bra Bicep-kod. Se till att koden du granskar följer samma metodtips.
- Matchar ändringen beskrivningen? Det är en bra idé för pull-begäranden att inkludera en beskrivande rubrik. Många team kräver också att pull-begäranden innehåller en beskrivning av ändringen och dess syfte. Kontrollera att ändringarna i din Bicep-kod matchar detaljerna i pull-begäran. Om pull-begärandeförfattaren har länkat till arbetsobjekt eller problem kontrollerar du att ändringarna i pull-begäran uppfyller de framgångsvillkor som arbetsobjektet har definierat.
Slutför en pull-begäran
När pull-begäran har godkänts kan den slutföras. Det innebär att innehållet i pull requesten sammanfogas i huvudgrenen.
I vissa team bör den som skapar en pull-begäran också avsluta den. Den här processen hjälper till att säkerställa att författaren styr när kopplingen sker och kan vara tillgänglig för att övervaka eventuella automatiserade distributioner. I andra team slutför godkännare pull-begäran. Ditt team bör bestämma vem som sammanfogar pullförfrågningar och när.
I vissa team bör den som skapar en pull-begäran också avsluta den. Den här processen hjälper till att säkerställa att författaren styr när kopplingen sker och kan vara tillgänglig för att övervaka eventuella automatiserade distributioner. I andra team slutför godkännare pull-begäran. Du kan till och med använda Azure DevOps för att automatiskt slutföra en pull-begäran när den uppfyller godkännandevillkoren. Ditt team bör bestämma vem som sammanfogar pullförfrågningar och när.
Din teams process
När du har börjat använda funktionsgrenar och pull-begäranden kan teamets process ändras till något som liknar följande:
En gruppmedlem klonar din delade lagringsplats.
De gör lokala ändringar på en gren i sin egen lokala kopia av lagringsplatsen.
När de är klara med ändringarna skickar de sin lokala gren till den delade lagringsplatsen.
I den delade lagringsplatsen skapar de en pull-begäran för att sammanfoga grenen till main.
Andra teammedlemmar granskar ändringarna. När de är nöjda godkänner de pull request och den sammanfogas till den delade lagringsplatsens huvudgren.
De tar bort grenarna på den delade lagringsplatsen och i sin lokala kopia av lagringsplatsen.
I vissa fall utlöser fjärrlagringsplatsens push-överföring en automatiserad pipeline för att verifiera, testa och distribuera koden. Du får lära dig mer om pipelines i andra Microsoft Learn-moduler.
Följande diagram illustrerar den här reviderade processen.