The Standard Change Process¶
A standard change is a pre-approved, low-risk change with a known procedure and fixed request fields. This page describes the process around it: how a request enters, which states it goes through, who does what, and which categories exist. The technical procedure per category is in the runbooks listed in Common requests. The reviewer and operator runbooks are in Reviewer and operator runbooks.
Everything that is not in the list of categories is not a standard change. It is handled as a project, as a development change in the code repository, or as an incident, depending on what it is.
Two ways to start a change¶
Which of the two is available depends on the agreement with your platform team (Operating models).
| Route | What the requester does | What the platform team does |
|---|---|---|
| A. Request | Describes the change in a ticket or work item (user story) and delivers all fields of the category. | Prepares the configuration change, has it reviewed, deploys it. |
| B. Pull request | Prepares the configuration change themselves as a pull request on the configuration repository, and links it to a ticket. | Reviews the pull request, merges it and deploys it. |
Route B suits teams that know the JSON formats. It is common for firewall rules and IP groups (Firewall rules and IP groups for workload teams) and for Managed VM configurations (Prepare a Managed VM pull request). The requester never completes their own pull request, and the pull request never replaces the ticket: the ticket is the change record.
Life cycle of a request¶
A ticket moves through a small set of states. The names below are an example from a work item board. Use the equivalent in your tooling.
| # | State | Who moves it | Meaning |
|---|---|---|---|
| 1 | New | Requester | The request is created. The requester completes all fields of the category, then moves it to Design. |
| 2 | Design | Platform team | The request is complete and ready to be picked up. The platform team checks it and asks questions if fields are missing. Then it becomes Active. |
| 3 | Active | Platform team | The platform team works on the change: edit, pull request, review, deploy. |
| 4 | Resolved | Platform team | The change is deployed and the team has verified the result in the apply logs. |
| 5 | Done | Requester | The requester has validated the result and accepts it. If it is not right, they move it back to Active with a comment. |
Rules:
- A request with missing fields goes back to the requester (state New) with a comment that says what is missing. The platform team does not guess.
- After Done, a new or additional change is a new ticket.
- Agree a target resolve time from Design to Resolved in your contract or internal agreement. A common target is a few working days, for example five. The time depends on the category and on the queue, and a production change needs a window. Put your value in your onboarding document, not in this documentation.
- A pull request that is linked to the ticket does not resolve the ticket automatically when it is merged. The ticket is resolved after the deployment is verified, so switch off complete the work item after merging in the auto-complete settings of the pull request.
Who does what in a pull request¶
| Step | Who |
|---|---|
| Prepare the change and open the pull request | The requester (route B) or the platform team (route A) |
| Approve the content | The owner of the workload, and security where the category needs it |
| Review technically | A platform engineer who did not write the change |
| Merge and deploy | The platform team |
The checklist for the review is in Pull request review.
Categories and request fields¶
Every request has the three common fields of Common requests: rationale, environment and comments. The table shows the extra fields per category. The runbook of the category shows where each field goes in the configuration.
| Category | Extra request fields | Runbook |
|---|---|---|
| New workload, spoke or application landing zone | Workload name, short name, description, usage type (production or non-production data), exposure to the internet, owner, team, IP range size (a /24 is a common default), subnets (name, size, delegations, service endpoints), team group and PIM mode |
New spoke |
| Change a spoke | Workload, spoke, what changes (only the fields that change) | Change spoke |
| Delete a spoke | Spoke, environment, confirmation of the workload owner | Delete spoke |
| Firewall rule (new or changed) | Workload, spoke, description, integration (which other workloads or on-premises systems it connects to), rule name, rule type (application or network), source, destination, protocol and port | Firewall rules |
| IP group (new or changed) | Name, purpose, the addresses, which rules use it | IP groups |
| Application Gateway: add or change a workload | Workload name, backend address (IP or FQDN), listener URL, listener port (HTTP or HTTPS), SSL certificate (mandatory for HTTPS), redirect yes or no, health probe (standard, or custom with path, protocol and interval) | Application Gateway |
| Renew or replace a certificate | Listener URL, certificate name | Replace a certificate |
| Policy assignment (new or update) | Policy or initiative name, scope | Policy assignments |
| Policy exemption | Policy or initiative, scope, category, justification, alternative measures, end date, approval | Policy exemptions |
| Enable or disable a platform feature | Feature or resource type, environment (production or non-production) | Platform features |
| Tags on hub resources (create, update, delete) | Tag name, tag value, environment | Hub tags |
| Managed VM (new, change, remove) | Spoke, configuration short name, and the VM settings that change | Managed VM module, fields in Request and change |
Older request forms
Older forms of the standard changes list the same fields under other names (for example Additional spoke canvas for a new spoke, and Workload Azure firewall rule). The catalog on this page follows the runbooks.
What is not a standard change¶
These are common requests that look like standard changes but are not. See the scope boundaries for the reasons.
- A feature that needs new Terraform in the code repository.
- Spoke tags: the workload team sets them in the spoke JSON.
- Policy initiatives on a single spoke: the workload team is responsible for them.
- Anything that has to be done by hand in the portal, outside the configuration repository, because the next deployment would undo it.