Het standaardwijzigingsproces¶
Een standaardwijziging is een vooraf goedgekeurde wijziging met laag risico, een bekende procedure en vaste aanvraagvelden. Deze pagina beschrijft het proces eromheen: hoe een aanvraag binnenkomt, welke statussen die doorloopt, wie wat doet en welke categorieën er zijn. De technische procedure per categorie staat in de runbooks in Veelvoorkomende aanvragen. De runbooks voor reviewers en operators staan in Runbooks voor reviewers en operators.
Alles wat niet in de lijst met categorieën staat, is geen standaardwijziging. Het wordt behandeld als project, als ontwikkelwijziging in de coderepository of als incident, afhankelijk van wat het is.
Twee manieren om een wijziging te starten¶
Welke van de twee beschikbaar is, hangt af van de afspraak met je platformteam (Beheermodellen).
| Route | Wat de aanvrager doet | Wat het platformteam doet |
|---|---|---|
| A. Aanvraag | Beschrijft de wijziging in een ticket of work item (user story) en levert alle velden van de categorie aan. | Bereidt de configuratiewijziging voor, laat die reviewen en deployt die. |
| B. Pull request | Bereidt de configuratiewijziging zelf voor als pull request op de configuratierepository en koppelt die aan een ticket. | Reviewt de pull request, merget en deployt. |
Route B past bij teams die de JSON-formaten kennen. Het is gebruikelijk voor firewallregels en IP groups (Firewallregels en IP groups voor workload teams) en voor Managed VM-configuraties (Een Managed VM pull request voorbereiden). De aanvrager rondt nooit zijn eigen pull request af, en de pull request vervangt het ticket nooit: het ticket is het wijzigingsrecord.
Levenscyclus van een aanvraag¶
Een ticket doorloopt een kleine set statussen. De namen hieronder zijn een voorbeeld van een work item board. Gebruik het equivalent in je eigen tooling.
| # | Status | Wie zet hem door | Betekenis |
|---|---|---|---|
| 1 | New | Aanvrager | De aanvraag is aangemaakt. De aanvrager vult alle velden van de categorie in en zet hem dan op Design. |
| 2 | Design | Platformteam | De aanvraag is compleet en klaar om opgepakt te worden. Het platformteam controleert hem en stelt vragen als er velden ontbreken. Daarna wordt hij Active. |
| 3 | Active | Platformteam | Het platformteam werkt aan de wijziging: bewerken, pull request, review, deploy. |
| 4 | Resolved | Platformteam | De wijziging is gedeployed en het team heeft het resultaat in de apply logs gecontroleerd. |
| 5 | Done | Aanvrager | De aanvrager heeft het resultaat gevalideerd en accepteert het. Klopt het niet, dan zet hij hem met een opmerking terug naar Active. |
Regels:
- Een aanvraag met ontbrekende velden gaat terug naar de aanvrager (status New) met een opmerking over wat er ontbreekt. Het platformteam gokt niet.
- Na Done is een nieuwe of aanvullende wijziging een nieuw ticket.
- Spreek een doelstelling voor de oplostijd af van Design tot Resolved in je contract of interne afspraak. Een gebruikelijke doelstelling is een paar werkdagen, bijvoorbeeld vijf. De tijd hangt af van de categorie en van de wachtrij, en een productiewijziging heeft een venster nodig. Zet je waarde in je onboardingdocument, niet in deze documentatie.
- Een pull request die aan het ticket is gekoppeld, lost het ticket niet automatisch op bij het mergen. Het ticket wordt opgelost nadat de deployment is gecontroleerd, dus schakel complete the work item after merging uit in de auto-complete-instellingen van de pull request.
Wie doet wat in een pull request¶
| Stap | Wie |
|---|---|
| De wijziging voorbereiden en de pull request openen | De aanvrager (route B) of het platformteam (route A) |
| De inhoud goedkeuren | De eigenaar van de workload, en security waar de categorie dat vereist |
| Technisch reviewen | Een platform engineer die de wijziging niet heeft geschreven |
| Mergen en deployen | Het platformteam |
De checklist voor de review staat in Pull request review.
Categorieën en aanvraagvelden¶
Elke aanvraag heeft de drie gemeenschappelijke velden uit Veelvoorkomende aanvragen: onderbouwing, omgeving en opmerkingen. De tabel toont de extra velden per categorie. Het runbook van de categorie laat zien waar elk veld in de configuratie terechtkomt.
| Categorie | Extra aanvraagvelden | Runbook |
|---|---|---|
| Nieuwe workload, spoke of application landing zone | Naam van de workload, korte naam, beschrijving, gebruikstype (productie- of niet-productiedata), blootstelling aan internet, eigenaar, team, grootte van het IP-bereik (een /24 is een gebruikelijke standaard), subnets (naam, grootte, delegaties, service endpoints), teamgroep en PIM-modus |
Nieuwe spoke |
| Een spoke wijzigen | Workload, spoke, wat er verandert (alleen de velden die veranderen) | Spoke wijzigen |
| Een spoke verwijderen | Spoke, omgeving, bevestiging van de eigenaar van de workload | Spoke verwijderen |
| Firewallregel (nieuw of gewijzigd) | Workload, spoke, beschrijving, integratie (met welke andere workloads of on-premises systemen die verbindt), regelnaam, regeltype (application of network), bron, bestemming, protocol en poort | Firewallregels |
| IP group (nieuw of gewijzigd) | Naam, doel, de adressen, welke regels hem gebruiken | IP groups |
| Application Gateway: een workload toevoegen of wijzigen | Naam van de workload, backendadres (IP of FQDN), listener-URL, listenerpoort (HTTP of HTTPS), SSL-certificaat (verplicht voor HTTPS), redirect ja of nee, health probe (standaard, of aangepast met pad, protocol en interval) | Application Gateway |
| Een certificaat vernieuwen of vervangen | Listener-URL, certificaatnaam | Een certificaat vervangen |
| Policy-toewijzing (nieuw of bijgewerkt) | Naam van de policy of initiative, scope | Policy-toewijzingen |
| Policy-uitzondering | Policy of initiative, scope, categorie, motivatie, alternatieve maatregelen, einddatum, goedkeuring | Policy-uitzonderingen |
| Een platformfunctie in- of uitschakelen | Functie of resourcetype, omgeving (productie of niet-productie) | Platformfuncties |
| Tags op hubresources (aanmaken, bijwerken, verwijderen) | Tagnaam, tagwaarde, omgeving | Hub tags |
| Managed VM (nieuw, wijzigen, verwijderen) | Spoke, korte naam van de configuratie en de VM-instellingen die veranderen | Managed VM-module, velden in Aanvragen en wijzigen |
Oudere aanvraagformulieren
Oudere formulieren van de standaardwijzigingen noemen dezelfde velden onder andere namen (bijvoorbeeld Additional spoke canvas voor een nieuwe spoke, en Workload Azure firewall rule). De catalogus op deze pagina volgt de runbooks.
Wat geen standaardwijziging is¶
Dit zijn veelvoorkomende aanvragen die op standaardwijzigingen lijken maar dat niet zijn. Zie de afbakening van de scope voor de redenen.
- Een functie die nieuwe Terraform in de coderepository nodig heeft.
- Spoke-tags: het workload team stelt ze in in de spoke-JSON.
- Policy initiatives op één enkele spoke: het workload team is er verantwoordelijk voor.
- Alles wat met de hand in de portal moet gebeuren, buiten de configuratierepository, omdat de volgende deployment het ongedaan zou maken.