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.
Hämta begäranden
En pull-begäran är en begäran från dig, utvecklaren av en funktion, till huvudgrenens underhållare. 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 projekt-leads som granskare för alla dina pull-begäranden, eller så kan du ange att ett visst antal personer måste granska varje pull-begäran.
Pull-begäranden och grenprinciper
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 projekt-leads som granskare för alla dina pull-begäranden, eller så kan du ange att ett visst antal personer måste granska varje pull-begäran.
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 namn på pull-begäranden 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-begäran kan du fortsätta att göra ändringar i koden på funktionsgrenen. Dessa ändringar blir en del av pull-begäran.
Granska en pull-begäran
När du granskar en pull-begäran 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. Heter variabler och parametrar bra? Har kommentarer använts för att förklara några komplexa kodavsnitt?
- Är ändringen klar? Om den här pull-begäran representerar en del av ett bredare arbete kontrollerar du att din miljö fungerar när den här ändringen sammanfogas och distribueras. 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 bra Bicep-metoder? 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 pull-begärandeinformationen. 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-begäran sammanfogas till huvudgrenen.
I vissa team bör pull-begärandeförfattaren också slutföra 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 pull-begäranden och när.
I vissa team bör pull-begärandeförfattaren också slutföra 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 pull-begäranden och när.
Teamets 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 uppfyllda godkänner de pull-begäran 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.
