This document outlines development guidance for contributions to the Managed Services Platform (MSP).

To get started, please familiarise yourself with the MSP offering by reading Managed Services Platform (MSP), and read MSP technical details for a high-level overview of MSP components.

Testing environments

Core Services has a test service that provisions several environments for use in testing: MSP Testbed infrastructure operations.

From time to time, we may need to test MSP platform changes in a more realistic use case and scenario. In these cases, we may reach out to teams that own test environments and use the above process to test platform changes directly for brief periods of time. This can result in brief breakages that will be communicated and resolved by Core Services.

Applying changes from dev builds

Dev builds of sg msp toolchains can be used to generate in-development versions of Terraform manifests (Generating infrastructure manifests). Use a go build invocation of your choice and run sg msp generate on a test service environment, preferably msp-testbed .

Core Services teammates can liberally place msp-testbed environments in “CLI-apply” mode to apply and test changes directly, before a new sg msp release is even merged and published. For more details on how “CLI-apply” mode works, see ‣. This can be used to run terraform apply using your local generated outputs.

When pushing in-development changes, if you put the generated diff up for review, make sure to add the no-generate label to the pull request to disable the automatic generated diff fixer.

Once your changes to sg msp have been merged, wait for the release to roll out via MSP infrastructure upgrades, then put the msp-testbed environment you have been working on back into VCS-apply mode:

sg msp tfc sync msp-testbed $ENV

Things to look out for in development

When building changes for MSP infrastructure, there are several key things to look out for:

1. Terraform resource re-creation: Does this change force a recreation when running terraform plan? This is visible from terraform plan as # forces replacement and ... must be replaced

   1. You can often work around this by changing the naming strategy of the resource based on the configuration that forces a replace, and applying the following in your CDKTF resource configuration:

   Lifecycle: &cdktf.TerraformResourceLifecycle{
     CreateBeforeDestroy: pointers.Ptr(true),
   },
   

2. Add your pro tip here!