Bicep-wijzigingen controleren en samenvoegen
U hebt geleerd hoe u functievertakkingen kunt gebruiken en vertakkingsbeveiliging kunt toepassen om ervoor te zorgen dat wijzigingen worden gecontroleerd voordat ze worden samengevoegd. Nu moet u een consistent proces volgen om uw wijzigingen voor te stellen en te controleren voordat ze worden samengevoegd.
In deze les leert u meer over pull-aanvragen, waaronder het maken en gebruiken ervan. U leert ook hoe u pull-aanvragen kunt gebruiken om Bicep-code te controleren.
Pull-aanvragen
Een pull-aanvraag is een aanvraag van u, de ontwikkelaar van een functie, aan de onderhouder van de hoofdbranch. U vraagt de onderhouder om uw wijzigingen op te halen in de hoofdbranch van de opslagplaats.
Pull-aanvragen en vertakkingsbeveiligingen
Wanneer u vertakkingsbeveiligingen configureert, kunt u vereisen dat uw code-eigenaren de pull-aanvraag controleren. U kunt bijvoorbeeld de projectleiders opnemen als revisoren voor al uw pull-aanvragen of u kunt opgeven dat een bepaald aantal personen elke pull-aanvraag moet controleren.
Pull-aanvragen en vertakkingsbeleid
Wanneer u vertakkingsbeleid configureert, kunt u specifieke personen of een groep personen vereisen om de pull-aanvraag te controleren. U kunt bijvoorbeeld de projectleiders opnemen als revisoren voor al uw pull-aanvragen of u kunt opgeven dat een bepaald aantal personen elke pull-aanvraag moet controleren.
U kunt ook vereisen dat elke pull-aanvraag is gekoppeld aan een werkitem. Met deze configuratie kunt u traceren vanaf een werkitem dat een functieaanvraag bevat naar de code waarmee de wijziging wordt geïmplementeerd, helemaal naar uw productieomgeving.
Een pull-aanvraag maken
U kunt een pull-aanvraag maken met behulp van de GitHub-webinterface. U selecteert de bronbranch, waar u uw wijzigingen hebt aangebracht en de doelbranch, meestal de hoofdbranch van de opslagplaats.
U kunt een pull-aanvraag maken met behulp van de Azure DevOps-webinterface. U selecteert de bronbranch, waar u uw wijzigingen hebt aangebracht en de doelbranch, meestal de hoofdbranch van de opslagplaats.
Wanneer u een pull-aanvraag maakt, moet u deze een naam geven. Het is een goede gewoonte om uw pull-aanvraagnamen duidelijk en begrijpelijk te maken. Deze procedure helpt uw teamleden inzicht te krijgen in de context van wat ze worden gevraagd om te beoordelen. Als ze verschillende expertisegebieden hebben, kan een goede naam hen helpen bij het vinden van pull-aanvragen, waar ze zinvolle feedback kunnen leveren en de pull-aanvragen kunnen overslaan die niet relevant zijn.
Ook worden namen van pull-aanvragen vaak onderdeel van de geschiedenis van uw Git-opslagplaats, dus het is een goed idee om ze begrijpelijk te maken wanneer iemand terugkijkt naar de geschiedenis.
U kunt ook pull-aanvragen een beschrijving geven. U kunt specifieke personen vermelden of verwijzen naar problemen in uw beschrijvingen. Veel teams maken gestandaardiseerde sjablonen voor beschrijvingen van pull-aanvragen, zodat duidelijk is wat elke wijziging is.
U kunt ook pull-aanvragen een beschrijving geven. U kunt specifieke personen vermelden of verwijzen naar werkitems in uw beschrijvingen. Veel teams maken gestandaardiseerde sjablonen voor beschrijvingen van pull-aanvragen, zodat duidelijk is wat elke wijziging is.
Wanneer u een pull-aanvraag maakt, kunt u personen uitnodigen om de wijzigingen te bekijken.
Soms maakt u een pull-aanvraag om feedback te krijgen van uw collega's. In deze situaties kunt u opgeven dat de pull-aanvraag een concept is. Revisoren weten dat u nog steeds aan de wijzigingen werkt. Uw revisoren kunnen nog steeds feedback geven, maar het is duidelijk dat de wijzigingen nog niet klaar zijn om samen te voegen. Wanneer u tevreden bent met uw wijzigingen, kunt u de conceptstatus verwijderen.
Zelfs nadat u een pull-aanvraag hebt gemaakt, kunt u wijzigingen aanbrengen in de code in uw functiebranch. Deze wijzigingen worden onderdeel van de pull-aanvraag.
Een pull-aanvraag controleren
Wanneer u een pull-aanvraag bekijkt, ziet u alle wijzigingen. U kunt opmerkingen maken over de hele pull-aanvraag of alleen op specifieke delen van de bestanden die zijn gewijzigd. De auteur van de pull-aanvraag kan reageren op opmerkingen en andere revisoren kunnen deelnemen aan discussies. Deze opmerkingenfuncties maken samenwerken aan pull-aanvragen een interactieve ervaring.
Wanneer u Bicep-code bekijkt, zoekt u naar de volgende belangrijke elementen:
- Kan het bestand worden geïmplementeerd? Implementeer en test de Bicep-code voordat deze wordt samengevoegd. Zorg ervoor dat er geen linterwaarschuwingen zijn en of de Azure-implementatie slaagt. In een toekomstige Microsoft Learn-module leert u meer over benaderingen voor het automatisch implementeren en verifiëren van uw wijzigingen.
- Is de Bicep-code duidelijk en begrijpelijk? Het is belangrijk dat iedereen in uw team uw Bicep-code begrijpt. Wanneer u een Bicep-bestand in een pull-aanvraag bekijkt, moet u ervoor zorgen dat u precies begrijpt waar elke wijziging voor staat. Hebben variabelen en parameters de naam bron? Zijn opmerkingen gebruikt om complexe codesecties uit te leggen?
- Is de wijziging voltooid? Als deze pull-aanvraag een deel van een breder werk vertegenwoordigt, moet u ervoor zorgen dat uw omgeving werkt wanneer deze wijziging wordt samengevoegd en geïmplementeerd. Als de pull-aanvraag bijvoorbeeld een Azure-resource opnieuw configureert ter voorbereiding op een latere wijziging, controleert u of de resource gedurende het hele proces correct blijft werken. Als de pull-aanvraag een nieuwe Azure-resource toevoegt die nog niet nodig is, kunt u overwegen of een voorwaarde tijdelijk moet worden toegevoegd, zodat de resource pas wordt geïmplementeerd als deze nodig is.
- Volgt de wijziging goede Bicep-procedures? In andere Microsoft Learn-modules hebt u geleerd over de elementen van goede Bicep-code. Zorg ervoor dat de code die u bekijkt dezelfde aanbevolen procedures volgt.
- Komt de wijziging overeen met de beschrijving? Het is een goede gewoonte voor pull-aanvragen om een beschrijvende titel op te nemen. Veel teams vereisen ook dat pull-aanvragen een beschrijving van de wijziging en het doel ervan bevatten. Controleer of de wijzigingen in uw Bicep-code overeenkomen met de details van de pull-aanvraag. Als de auteur van de pull-aanvraag is gekoppeld aan werkitems of problemen, controleert u of de wijzigingen in de pull-aanvraag voldoen aan de succescriteria die het werkitem heeft gedefinieerd.
Een pull-aanvraag voltooien
Nadat de pull-aanvraag is goedgekeurd, kan deze worden voltooid. Dit betekent dat de inhoud van de pull-aanvraag wordt samengevoegd in de hoofdbranch.
In sommige teams moet de auteur van de pull-aanvraag deze ook voltooien. Dit proces zorgt ervoor dat de auteur bepaalt wanneer de samenvoegbewerking plaatsvindt en beschikbaar is om geautomatiseerde implementaties te controleren. In andere teams voltooien goedkeurders de pull-aanvraag. Uw team moet bepalen wie pull-aanvragen samenvoegt en wanneer.
In sommige teams moet de auteur van de pull-aanvraag deze ook voltooien. Dit proces zorgt ervoor dat de auteur bepaalt wanneer de samenvoegbewerking plaatsvindt en beschikbaar is om geautomatiseerde implementaties te controleren. In andere teams voltooien goedkeurders de pull-aanvraag. U kunt zelfs Azure DevOps gebruiken om automatisch een pull-aanvraag te voltooien wanneer deze voldoet aan de goedkeuringscriteria. Uw team moet bepalen wie pull-aanvragen samenvoegt en wanneer.
Het proces van uw team
Nadat u functiebranches en pull-aanvragen hebt gebruikt, kan het proces van uw team veranderen in iets als het volgende:
Een teamlid kloont uw gedeelde opslagplaats.
Ze brengen lokale wijzigingen aan in een vertakking in hun eigen lokale kopie van de opslagplaats.
Wanneer ze klaar zijn met hun wijzigingen, pushen ze hun lokale vertakking naar de gedeelde opslagplaats.
In de gedeelde opslagplaats maken ze een pull-aanvraag om de vertakking samen te voegen naar het hoofd.
Andere teamleden controleren de wijzigingen. Wanneer ze tevreden zijn, keuren ze de pull-aanvraag goed en worden ze samengevoegd met de hoofdvertakking van de gedeelde opslagplaats.
Ze verwijderen de vertakkingen in de gedeelde opslagplaats en in hun lokale kopie van de opslagplaats.
In sommige scenario's activeert de push van de externe opslagplaats een geautomatiseerde pijplijn om de code te verifiëren, te testen en te implementeren. Meer informatie over pijplijnen vindt u in andere Microsoft Learn-modules.
In het volgende diagram ziet u dit herziene proces.
