Förstå validering av pull-begäran
När du använder pull-begäranden kan du se till att en annan person granskar eventuella uppdateringar av dina Azure-distributioner. Det är dock ofta bra att automatiserade kontroller körs på dina kodändringar också. I den här lektionen får du lära dig hur du kan använda automatisk validering av pull-begäranden och kontroller för att öka teamets förtroende för dina kodändringar.
Validering av pull-begäran
När du granskar en pull-begäran för Bicep-kod kan du ha några vanliga steg som du går igenom för att utvärdera ändringen. De här stegen kan vara:
- Kontrollerar om Bicep-filen har några fel eller lintervarningar.
- Se till att alla resurser som tidigare definierats i Bicep-filen fortsätter att fungera.
- Testa alla nyligen definierade resurser för att säkerställa att de har distribuerats korrekt och att de fungerar som förväntat.
Validering av pull-begäran omfattar automatisering av vissa av dessa aktiviteter. När du automatiserar kontroller av pull-begäranden kan granskarna ägna sin tid åt andra viktigare granskningssteg, till exempel att se till att koden uppfyller teamets kvalitetsstandarder och uppnår affärsmålet.
I ett GitHub Actions-arbetsflöde kan du definiera utlösare som anropar arbetsflödet vid vissa tidpunkter under pull-begärandeprocessen, inklusive när en pull-begäran skapas, uppdateras, sammanfogas eller stängs.
Testa Bicep-koden i ett valideringsarbetsflöde för pull-begäran
I tidigare moduler har du lärt dig hur du skapar omfattande GitHub Actions-arbetsflöden för linting, validering, distribution och testning av ändringar i Din Azure-infrastruktur, inklusive i flera miljöer. Dessa arbetsflöden körs när du har sammanfogat ändringarna till huvudgrenen.
Du kan också köra många av samma aktiviteter i ett valideringsarbetsflöde för pull-begäranden. Till exempel:
- Linting av Bicep-koden hjälper till att säkerställa att koden är semantiskt korrekt och att den följer vissa rekommenderade Bicep-metoder för baslinje.
- Preflight-validering hjälper dig att skapa ditt förtroende för att koden kommer att distribueras utan att du behöver distribuera filen. Beroende på resurstyp kan preflight-validering söka efter problem som ogiltiga resursnamn, ogiltiga regioner för specifika resurser och om du har angett en konfiguration som inte kan distribueras.
- What-if, som visar de ändringar som kommer att göras i Din Azure-miljö som ett resultat av distributionen.
- Distributioner, för att faktiskt distribuera dina resurser och se till att det inte finns några distributionsfel.
- Testa dina resurser efter distributionen för att säkerställa att de är konfigurerade enligt dina affärskrav.
Ett valideringsarbetsflöde för pull-begäran är ett normalt GitHub Actions-arbetsflöde, så det kan köra någon av dessa uppgifter. Det är dock värt att tänka på vilka typer av kontroller som är meningsfulla att köra i en pull-begäran. Många av valideringsaktiviteterna som anges här kräver åtkomst till en Azure-miljö. Konsekvensåtgärden jämför till exempel de resurser som definierats i dina Bicep-filer med resurser i din Azure-prenumeration . Det är klokt att köra den här jämförelsen mot en produktionsmiljö, men eftersom det medför ytterligare risker kanske du inte är bekväm med att köra åtgärder mot en produktionsmiljö från ett arbetsflöde som är utformat för kod som ännu inte har slutförts eller sammanfogats.
I den här modulen lägger du till två typer av kontroller i valideringsarbetsflödet för pull-begäran:
- Linting din Bicep-kod för att köra en första uppsättning kontroller på den.
- Distribuera koden till en helt ny tillfällig miljö.
Dessa två aktiviteter kräver inte att du ansluter till din Azure-produktionsmiljö, eller ens till någon av dina vanliga icke-produktionsmiljöer, till exempel Test, QA eller Mellanlagring. Genom att köra de här två aktiviteterna kan du fortfarande bygga upp en stor mängd förtroende för dina kodändringar så att du kan slå samman dem till lagringsplatsens huvudgren.
Kontrollerna är användbara för granskarna eftersom de sparar tid som annars skulle spenderas på att köra aktiviteterna manuellt. Kontrollerna är också användbara för dig som pull-begärandeförfattare, eftersom du kan använda dem för att få en första vy över hur ändringarna kommer att fungera senare i distributionsprocessen.
I dina egna arbetsflöden för validering av pull-begäranden kan du välja att utöka verifieringskontrollerna med ytterligare aktiviteter.
Livscykelutlösare för pull-begäran
En pull-begäran i GitHub kan gå igenom många olika livscykelhändelser. Till exempel öppnas en pull-begäran. Författaren kan sedan skicka ändringar till källgrenen (synkronisera), vilket påverkar pull-begärans innehåll. Därefter kan pull-begäran slås samman, stängas utan att sammanfogas och till och med öppnas igen i framtiden.
Med GitHub Actions kan du definiera arbetsflödesutlösare som svarar på någon av dessa händelser. Du kan till exempel definiera ett arbetsflöde som körs automatiskt när en pull-begäran öppnas, synkroniseras eller öppnas igen genom att pull_request ange utlösaren utan någon ytterligare konfiguration:
on: pull_request
Du kan också ange händelser för pull-begäranden som utlöser ett arbetsflöde. Följande arbetsflöde körs till exempel automatiskt när en pull-begäran stängs:
on:
pull_request:
types: [closed]
Viktigt!
Om det finns sammanslagningskonflikter i en pull-begäran körs inte arbetsflödet. Du måste lösa konflikten och push-överföra lösningen så att arbetsflödet kan köras.
Statuskontroller för pull-begäranden
Resultatet av ett arbetsflöde för pull-begäran visas på informationssidan för pull-begäran som kontroller. Kontroller gör det möjligt för författare och granskare att snabbt få feedback om huruvida de automatiserade aktiviteterna har lyckats eller misslyckats, vilket visas i följande exempel:
Även om en kontroll misslyckas kan pull-begäran som standard sammanfogas. Du kanske inte vill tillåta detta, så du kan konfigurera regler för grenskydd för att framtvinga att specifika kontroller måste lyckas innan en pull-begäran kan sammanfogas.
Uppdatera filer
När en pull-begäran har skapats är det vanligt att en författare behöver göra uppdateringar. Till exempel:
- En granskare kan be författaren att göra ändringar i koden.
- Om en automatisk kontroll misslyckas kan författaren ändra koden för att åtgärda problemet och sedan checka in och push-överföra ändringarna.
Genom att använda utlösaren pull_request kan du konfigurera valideringsarbetsflödet så att det körs varje gång källgrenen uppdateras. Resultatet av arbetsflödets senaste körning visas på informationssidan för pull-begäran.
Återanvändbara arbetsflöden
Om du tittar på listan över möjliga kontroller för validering av pull-begärande ser du att det är samma steg som du skulle köra i ett vanligt distributionsarbetsflöde. För att undvika upprepning är det en bra idé att använda gitHub-återanvändbara arbetsflöden.
Du kan definiera återanvändbara arbetsflöden för vart och ett av de jobb som du ska använda i de olika arbetsflödesdefinitionerna. Du får se hur du gör detta i nästa övning.
Utkast till pull-begäranden
Som författare öppnar du vanligtvis en pull-begäran när du är redo för att dina ändringar ska granskas, godkännas och sammanfogas. Det kan dock vara bra att få åtkomst till valideringskontrollerna för automatiserade pull-begäranden under hela processen med att skriva koden, även om du ännu inte är redo för att dina ändringar ska sammanfogas.
När du öppnar en pull-begäran på GitHub kan du markera den som ett utkast. GitHub kör samma automatiserade kontroller och granskare kan fortfarande ge feedback. När din pull-begäran är i utkaststatus är det dock uppenbart för alla att arbetet ännu inte är redo för en fullständig granskning och att det inte kan sammanfogas.
Det är särskilt vanligt att skapa pull-begäranden när valideringsarbetsflödet för pull-begäranden skapar tillfälliga miljöer, eftersom du kan förhandsgranska ändringarna i en aktiv arbetsmiljö. När du fortsätter att push-överföra ändringar uppdateras din tillfälliga miljö för att införliva dina senaste ändringar.