Skip to content

Prepare a Managed VM Pull Request

If your platform team gave you access to the configuration repository, you can prepare a change to your managed VMs yourself as a pull request, instead of filling in a request form. The platform team still reviews, merges and deploys it. This page shows what to prepare, what the reviewer checks, and what you can expect.

Ask your platform team whether this route is open to you. The fields and their meaning are on Request and change. The reviewer's runbook is Managed VM pull request review.

What you do

  1. Open a ticket for the change and note its number. The ticket is the change record. The pull request links to it.
  2. Create a branch from main in the configuration repository.
  3. Edit the VM configuration file of your spoke and environment. There is one file per spoke and environment. For a new spoke, start from the template file of the environment, or copy a working file and adapt it.
  4. Open a pull request to main. Give it a title and a description that say which spoke, which VM configuration and which change, and link the ticket.
  5. Wait for the checks. The validation pipeline scans the code, validates it and plans the change. Fix what it reports and push again. It runs again by itself.
  6. Ask for the review: write a comment on the ticket that the pull request is ready.
  7. Do not complete the pull request yourself. The platform team merges it and deploys.

A new spoke folder

The module pipeline deploys only the spokes that are in its list. For a new folder, ask the platform team to add the spoke to that list, and mention it in the ticket. Without it nothing is deployed, and the pipeline stays green.

What the reviewer checks

Knowing the checks saves you a round trip.

Check What the reviewer looks at
The state of the pull request It is not a draft, the checks passed, there are no conflicts and all comments are resolved.
File and folder The file is in the folder of the right spoke, follows the naming for the environment and is in the pipeline list.
Existing spoke The subscription and the resource group are those of an existing spoke.
Completeness All variables exist and are well formed. The reviewer compares your file with a working one.
Hub connection The connectivity version is the same as in the existing deployments.
Access and owners Bastion and login settings are present. Owners are defined and exist in Entra ID.
Tags The tags are well formed, and PatchPriority has a valid value.
Names The workload short name and the configuration short name together are not too long.
Access packages If you set them to true, the reviewer may ask whether you want that. Some platforms prefer not to use them.
Instances The number is what you asked for. A value above 1 creates several VMs with the same configuration and numbered names.
Backup A backup solution is defined. The Recovery Services vault is the preferred one.
Disks The OS disk size is your choice. Data disks are optional. A removed data disk is checked against the list position, because the positions of the other disks shift.
Size A new size restarts the VM. The reviewer checks the quota, and that you agreed a time.

Changes that are allowed

These are normal, valid changes of a VM configuration:

  • a new VM configuration;
  • a new size (SKU);
  • a change of tags;
  • a change of the retention or the backup;
  • a change of the owners;
  • a change of the number of instances;
  • access packages on or off.

Everything else, for example a new option of the module or another image that is not yet offered, is a change of the module and goes through the platform team (Support).

After the merge

The platform team runs the pipeline for the right spoke and environment. Development and test and non-production environments are normally deployed after the build, production after an approval. You get a message on the ticket when the deployment is done and verified. Then check:

If the plan fails

The platform team sends you the error. Typical causes are a missing variable, a wrong format, a name that is too long or a size that is not available in the region or in your quota (Quota and capacity problems). Fix the file in your branch and push it.