Inzicht in validatie van pull-aanvragen
Wanneer u pull-aanvragen gebruikt, kunt u ervoor zorgen dat iemand anders alle updates voor uw Azure-implementaties beoordeelt. Het is echter vaak handig om automatische controles uit te voeren op uw codewijzigingen. In deze les leert u hoe u geautomatiseerde validatie van pull-aanvragen en controles kunt gebruiken om het vertrouwen van uw team in uw codewijzigingen te vergroten.
Validatie van pull-aanvraag
Wanneer u een pull-aanvraag voor Bicep-code bekijkt, hebt u mogelijk enkele algemene stappen die u moet uitvoeren om de wijziging te beoordelen. Deze stappen kunnen bestaan uit:
- Controleren of het Bicep-bestand fouten of linterwaarschuwingen bevat.
- Ervoor zorgen dat alle eerder gedefinieerde resources in het Bicep-bestand blijven werken.
- Test alle nieuw gedefinieerde resources om ervoor te zorgen dat ze correct worden geïmplementeerd en dat ze werken zoals verwacht.
Validatie van pull-aanvragen omvat het automatiseren van een aantal van deze activiteiten. Wanneer u controles voor pull-aanvragen automatiseert, kunnen uw revisoren hun tijd besteden aan andere belangrijke controlestappen, zoals ervoor zorgen dat de code voldoet aan de kwaliteitsnormen van uw team en het bedrijfsdoel bereikt.
In een GitHub Actions-werkstroom kunt u triggers definiëren die de werkstroom op bepaalde punten aanroepen tijdens het pull-aanvraagproces, inclusief wanneer een pull-aanvraag wordt gemaakt, bijgewerkt, samengevoegd of gesloten.
Uw Bicep-code testen in een validatiewerkstroom voor pull-aanvragen
In eerdere modules hebt u geleerd hoe u uitgebreide GitHub Actions-werkstromen bouwt voor linting, validatie, implementatie en het testen van wijzigingen in uw Azure-infrastructuur, inclusief in meerdere omgevingen. Deze werkstromen worden uitgevoerd nadat u de wijzigingen in uw hoofdbranch hebt samengevoegd.
U kunt ook veel van dezelfde activiteiten uitvoeren in een validatiewerkstroom voor pull-aanvragen. Voorbeeld:
- Door uw Bicep-code te linten , zorgt u ervoor dat de code semantisch correct is en dat deze een aantal aanbevolen Bicep-procedures volgens de basislijn volgt.
- Met preflight-validatie kunt u uw vertrouwen vergroten dat de code correct wordt geïmplementeerd zonder dat u het bestand daadwerkelijk hoeft te implementeren. Afhankelijk van het resourcetype kan de preflight-validatie zoeken naar problemen zoals ongeldige resourcenamen, ongeldige regio's voor specifieke resources en of u een configuratie hebt opgegeven die niet kan worden geïmplementeerd.
- Wat-als, waarin de wijzigingen worden vermeld die worden aangebracht in uw Azure-omgeving als gevolg van de implementatie.
- Implementaties, om uw resources daadwerkelijk te implementeren en ervoor te zorgen dat er geen implementatiefouten zijn.
- Test uw resources na de implementatie om ervoor te zorgen dat ze zijn geconfigureerd op basis van uw bedrijfsvereisten.
Een werkstroom voor validatie van pull-aanvragen is een normale GitHub Actions-werkstroom, zodat een van deze taken kan worden uitgevoerd. Het is echter de moeite waard om na te denken over de typen controles die zinvol zijn om te worden uitgevoerd binnen een pull-aanvraag. Veel van de hier vermelde validatieactiviteiten vereisen toegang tot een Azure-omgeving. De wat-als-bewerking vergelijkt bijvoorbeeld de resources die zijn gedefinieerd in uw Bicep-bestanden met resources in uw Azure-abonnement. Het is zinvol om deze vergelijking uit te voeren met een productieomgeving, maar omdat dit een extra risico veroorzaakt, bent u mogelijk niet vertrouwd met het uitvoeren van bewerkingen in een productieomgeving vanuit een werkstroom die is ontworpen voor code die nog niet is voltooid of samengevoegd.
In deze module voegt u twee soorten controles toe aan uw validatiewerkstroom voor pull-aanvragen:
- Linting van uw Bicep-code om er een eerste set controles op uit te voeren.
- De code implementeren in een gloednieuwe tijdelijke omgeving.
Voor deze twee activiteiten hoeft u geen verbinding te maken met uw Azure-productieomgeving of zelfs met een van uw reguliere niet-productieomgevingen, zoals Testen, QA of Fasering. Door deze twee activiteiten uit te voeren, kunt u nog steeds een goede mate van vertrouwen opbouwen in uw codewijzigingen, zodat u ze kunt samenvoegen in de hoofdbranch van uw opslagplaats.
De controles zijn handig voor uw revisoren, omdat ze tijd besparen die anders handmatig zou worden besteed aan het uitvoeren van de activiteiten. De controles zijn ook handig voor u als auteur van de pull-aanvraag, omdat u ze kunt gebruiken om een eerste weergave te krijgen van de werking van uw wijzigingen later in het implementatieproces.
In uw eigen werkstromen voor pull-aanvraagvalidatie kunt u ervoor kiezen om de validatiecontroles uit te breiden met aanvullende activiteiten.
Levenscyclustriggers voor pull-aanvragen
Een pull-aanvraag in GitHub kan veel verschillende levenscyclus-gebeurtenissen doorlopen. Een pull-aanvraag wordt bijvoorbeeld geopend. Vervolgens kan de auteur wijzigingen naar de bronbranch pushen (synchroniseren), wat van invloed is op de inhoud van de pull-aanvraag. Vervolgens kan de pull-aanvraag worden samengevoegd, gesloten zonder dat deze wordt samengevoegd en in de toekomst zelfs opnieuw wordt geopend .
Met GitHub Actions kunt u werkstroomtriggers definiëren die reageren op een van deze gebeurtenissen. U kunt bijvoorbeeld een werkstroom definiëren die automatisch wordt uitgevoerd wanneer een pull-aanvraag wordt geopend, gesynchroniseerd of opnieuw wordt geopend door de pull_request trigger op te geven zonder aanvullende configuratie:
on: pull_request
U kunt ook gebeurtenissen voor pull-aanvragen opgeven die een werkstroom activeren. De volgende werkstroom wordt bijvoorbeeld automatisch uitgevoerd wanneer een pull-aanvraag wordt gesloten:
on:
pull_request:
types: [closed]
Belangrijk
Als er samenvoegingsconflicten in een pull-aanvraag zijn, wordt de werkstroom niet uitgevoerd. U moet het conflict oplossen en de oplossing pushen, zodat de werkstroom kan worden uitgevoerd.
Statuscontroles van pull-aanvragen
De resultaten van een werkstroom voor pull-aanvragen worden weergegeven op de detailpagina van de pull-aanvraag als controles. Met controles kunnen auteurs en revisoren snel feedback krijgen over of de geautomatiseerde activiteiten zijn geslaagd of mislukt, zoals wordt weergegeven in het volgende voorbeeld:
Zelfs als een controle mislukt, kan de pull-aanvraag standaard worden samengevoegd. Mogelijk wilt u dit niet toestaan, dus u kunt vertakkingsbeveiligingsregels configureren om af te dwingen dat specifieke controles moeten slagen voordat een pull-aanvraag kan worden samengevoegd.
Bestanden bijwerken
Nadat een pull-aanvraag is gemaakt, is het gebruikelijk dat een auteur updates moet aanbrengen. Voorbeeld:
- Een revisor kan de auteur vragen om wijzigingen aan te brengen in de code.
- Als een automatische controle mislukt, kan de auteur de code wijzigen om het probleem op te lossen en de wijzigingen doorvoeren en pushen.
Met behulp van de pull_request trigger kunt u uw validatiewerkstroom zo configureren dat deze wordt uitgevoerd telkens wanneer de bronbranch wordt bijgewerkt. De resultaten van de meest recente uitvoering van de werkstroom worden weergegeven op de detailpagina van de pull-aanvraag.
Herbruikbare werkstromen
Als u de lijst met mogelijke controles voor validatie van pull-aanvragen bekijkt, ziet u dat deze dezelfde stappen zijn die u in een normale implementatiewerkstroom zou uitvoeren. Om herhaling te voorkomen, is het een goede gewoonte om de herbruikbare Werkstromen van GitHub te gebruiken.
U kunt herbruikbare werkstromen definiëren voor elk van de taken die u in de verschillende werkstroomdefinities gaat gebruiken. In de volgende oefening ziet u hoe u dit doet.
Concepten maken van pull-aanvragen
Als auteur opent u gewoonlijk een pull-aanvraag wanneer u klaar bent om uw wijzigingen te controleren, goedgekeurd en samengevoegd. Het kan echter handig zijn om tijdens het schrijven van uw code toegang te krijgen tot de automatische validatiecontroles voor pull-aanvragen, zelfs als u nog niet klaar bent om uw wijzigingen samen te voegen.
Wanneer u een pull-aanvraag op GitHub opent, kunt u deze markeren als concept. GitHub voert dezelfde geautomatiseerde controles uit en revisoren kunnen nog steeds feedback geven. Wanneer uw pull-aanvraag echter de conceptstatus heeft, is het voor iedereen duidelijk dat het werk nog niet gereed is voor een volledige beoordeling en niet kan worden samengevoegd.
Het is vooral gebruikelijk om concept-pull-aanvragen te maken wanneer uw pull-aanvraagvalidatiewerkstroom tijdelijke omgevingen maakt, omdat u een voorbeeld van uw wijzigingen in een live, werkomgeving kunt bekijken. Wanneer u wijzigingen blijft pushen, wordt uw tijdelijke omgeving bijgewerkt om uw meest recente wijzigingen op te nemen.