Skip to content

Managed VM Pull Request Review and Deployment

Reviewer and operator runbook for pull requests that add or change the configuration of managed virtual machines. It describes how to validate the pull request, which settings need a second look, how to run the module pipeline and how to handle errors. The module itself, the request fields and the regular checks are in Managed VM module (platform side). The view of the workload team is in Prepare a Managed VM pull request.

Scope

The runbook applies to:

  • pull requests for the configuration of managed VMs (new VM deployments and changes to existing VM configurations);
  • the configuration repository of the spokes and of the Managed VM module;
  • development/test, non-production and production environments.

The objective is a consistent and correct configuration, and a safe deployment of virtual machines into the spokes.

1. Preparation

Make sure you have access to the tooling of the platform (the repository, the pipelines and the ticket system) and to the repository of the right customer or platform environment.

2. Check the state of the pull request

Check Action when it fails
The pull request is not a draft Comment on the ticket: the requester must finish it first.
The required checks passed Queue the pipeline again if the result expired. If it failed, ask the requester to fix it before the review continues.
All comments are resolved Ask the requester to resolve them.
A ticket is linked Link it, or make the check optional if your process allows.
You know the requester They are shown under the title. Address your comments to them.

Required checks depend on the platform

The validation pipeline as a required check is not available everywhere. Where it is not, validate the files yourself.

3. Review the configuration

3.1 What kind of change is it

Find out whether the pull request is a new VM configuration or a change to an existing VM: size, tags, retention, owners, number of instances and so on. The supported change types are listed in Change types that fit a standard change. Everything else is not a standard change.

3.2 Files and folders

The configuration file:

  • is in the folder of the right spoke;
  • follows the naming of the platform for the environment (for example prod, nonprod or dev);
  • is included in the pipeline configuration.

New folders and files must be referenced in the pipeline

A spoke folder that is not in the list of spokes of the module pipeline is not deployed, and the pipeline stays green. Check that the pull request adds the reference.

3.3 Content

There is no single field to check on its own: all variables must be present and correct. Compare the new file with an existing, working configuration, with a file comparison tool, and make sure all expected variables exist and are well formed. Check these by eye:

  • the subscription ID and the resource group refer to an existing spoke;
  • the version of the connectivity module is the same as in existing deployments (for example connectivity_v1);
  • the Bastion and login settings are present;
  • the owners are defined, and are people that exist in Entra ID;
  • the tags have the right format, and PatchPriority is a valid value;
  • the combined length of the workload short name and the configuration short name is within the limit (Request fields).

3.4 Settings that need a second look

Setting Check
useAccessPackages May be true or false. Some platforms no longer use access packages and prefer false. If it is true, ask the requester whether that is intended.
instances Number of VMs. With a value above 1, several VMs with the same configuration are created, with the standard names and an incrementing suffix. Check that the number is the one that was asked for.
Backup A backup solution must be defined. The Recovery Services vault is the preferred one, the Backup Vault is the older option that is still supported.
Disks The OS disk size is chosen by the customer. Data disks are optional: missing data disks are fine unless the plan fails. When a data disk is removed, check the index (it is the position in the list) and that the data is not needed.
Size (SKU) A resize restarts the VM. Check the quota and agree on a time.

4. Run the pipeline

4.1 Which pipeline

Use the Managed VM deployment pipeline. For the validation of a pull request, select the branch of the pull request. For the deployment after the merge, use main.

4.2 Which stage

  1. Deselect all stages.
  2. Search for and select the stage that matches the spoke name and the environment (development/test, non-production, production).
  3. Make sure the stage matches the name of the configuration file.

4.3 Deployment flow

  • The build phase runs the Terraform plan. If it fails, send the error to the author of the pull request and ask for a correction.
  • Development/test and non-production deploy automatically after the build.
  • Production waits for an approval of a second engineer. Read the plan again before you approve.

4.4 Verify the apply

After the apply stage is green:

  1. Open the apply log.
  2. Check that the requested change was carried out.
  3. Do not rely on the green stage alone. If the change is not visible, do not consider the deployment successful. Investigate, and ask a second engineer if needed.

5. Final review and close

  • All checks in order: approve the pull request, deploy, and verify.
  • Update the ticket: say that the change is deployed, assign it to the requester, and move it to Resolved.
  • Tell the requester how to connect and where the credentials are (Connect to virtual machines).

6. Error handling

Problem Action
Terraform plan fails Send the error output to the requester and ask for an update of the pull request.
The error is unclear or complex Ask a second platform engineer.
Nothing is deployed, the pipeline is green The spoke folder is not in the module pipeline. Add it.
The Key Vault name is wrong Set key_vault_name explicitly (Request fields).