Ga naar inhoud

Een pull request voor een managed VM voorbereiden

Als je platformteam je toegang heeft gegeven tot de configuratierepository, kun je een wijziging aan je managed VM's zelf voorbereiden als pull request, in plaats van een aanvraagformulier in te vullen. Het platformteam reviewt, merget en deployt het nog steeds. Deze pagina laat zien wat je voorbereidt, wat de reviewer controleert en wat je kunt verwachten.

Vraag je platformteam of deze route voor jou openstaat. De velden en hun betekenis staan op Aanvragen en wijzigen. Het runbook van de reviewer is Review van een managed VM pull request.

Wat jij doet

  1. Open een ticket voor de wijziging en noteer het nummer. Het ticket is het wijzigingsrecord. De pull request linkt ernaar.
  2. Maak een branch vanaf main in de configuratierepository.
  3. Bewerk het VM-configuratiebestand van je spoke en omgeving. Er is één bestand per spoke en omgeving. Begin voor een nieuwe spoke met het templatebestand van de omgeving, of kopieer een werkend bestand en pas het aan.
  4. Open een pull request naar main. Geef die een titel en een beschrijving die zeggen om welke spoke, welke VM-configuratie en welke wijziging het gaat, en link het ticket.
  5. Wacht op de checks. De validatiepipeline scant de code, valideert die en plant de wijziging. Los op wat de pipeline meldt en push opnieuw. De pipeline draait dan vanzelf opnieuw.
  6. Vraag om de review: schrijf een opmerking op het ticket dat de pull request klaar is.
  7. Rond de pull request niet zelf af. Het platformteam merget en deployt.

Een nieuwe spokemap

De modulepipeline deployt alleen de spokes die in zijn lijst staan. Vraag het platformteam bij een nieuwe map om de spoke aan die lijst toe te voegen, en vermeld dat in het ticket. Zonder dat wordt er niets gedeployed, en blijft de pipeline groen.

Wat de reviewer controleert

Als je de checks kent, bespaar je een extra ronde.

Check Waar de reviewer naar kijkt
De status van de pull request Het is geen draft, de checks zijn geslaagd, er zijn geen conflicten en alle opmerkingen zijn opgelost.
Bestand en map Het bestand staat in de map van de juiste spoke, volgt de naamgeving voor de omgeving en staat in de pipelinelijst.
Bestaande spoke De subscription en de resource group zijn die van een bestaande spoke.
Volledigheid Alle variabelen bestaan en zijn goed opgebouwd. De reviewer vergelijkt je bestand met een werkend bestand.
Hubverbinding De connectivityversie is dezelfde als in de bestaande deployments.
Toegang en owners Bastion- en logininstellingen zijn aanwezig. Owners zijn gedefinieerd en bestaan in Entra ID.
Tags De tags zijn goed opgebouwd, en PatchPriority heeft een geldige waarde.
Namen De korte naam van de workload en de korte naam van de configuratie samen zijn niet te lang.
Access packages Als je ze op true zet, kan de reviewer vragen of je dat wilt. Sommige platforms gebruiken ze liever niet.
Instances Het aantal is wat je hebt gevraagd. Een waarde boven 1 maakt meerdere VM's met dezelfde configuratie en genummerde namen.
Back-up Er is een back-upoplossing gedefinieerd. De Recovery Services vault heeft de voorkeur.
Schijven De grootte van de OS-disk is jouw keuze. Datadisks zijn optioneel. Bij een verwijderde datadisk wordt de positie in de lijst gecontroleerd, omdat de posities van de andere disks verschuiven.
Grootte Een nieuwe grootte herstart de VM. De reviewer controleert de quota, en of je een tijd hebt afgesproken.

Wijzigingen die zijn toegestaan

Dit zijn normale, geldige wijzigingen van een VM-configuratie:

  • een nieuwe VM-configuratie;
  • een nieuwe grootte (SKU);
  • een wijziging van tags;
  • een wijziging van de retentie of de back-up;
  • een wijziging van de owners;
  • een wijziging van het aantal instances;
  • access packages aan of uit.

Al het andere, bijvoorbeeld een nieuwe optie van de module of een andere image die nog niet wordt aangeboden, is een wijziging van de module en loopt via het platformteam (Support).

Na de merge

Het platformteam draait de pipeline voor de juiste spoke en omgeving. Development-, test- en non-productieomgevingen worden normaal gedeployed na de build, productie na een goedkeuring. Je krijgt een bericht op het ticket als de deployment klaar en geverifieerd is. Controleer dan:

Als het plan faalt

Het platformteam stuurt je de foutmelding. Typische oorzaken zijn een ontbrekende variabele, een verkeerd formaat, een te lange naam of een grootte die niet beschikbaar is in de regio of in je quota (Quota- en capaciteitsproblemen). Pas het bestand in je branch aan en push het.