Bridge-To-Kubernetes/deployment

Release Process

These instructions describe how to take changes from the main branch and move them through the various processes and pipelines to release them to customers.

Contents

• Build and Release pipelines
• Dev
• Staging
  • Preparation
  • Snap main into the staging branch
  • Release
• Production
  • Preparation
  • Snap staging into the production branch
  • Release
  • Hotfix
• Appendix
  • Analysis and sanity builds
  • Prerequisites to snap
  • Notes

Build and Release pipelines

Build	Release	Component
TBD	TBD on new git pipelines	TBD on new git pipelines

Dev

Whenever a change is merged into the main branch, the Build and release pipelines produce updated components and automatically release them into the Dev environment. No manual intervention is needed unless a pipeline fails.

Component	Released to	Download
Service images	mindarodev Azure Container Registry	mindarodev.azurecr.io/routingmanager:latest mindarodev.azurecr.io/lpkremoteagent:latest mindarodev.azurecr.io/lpkrestorationjob:latest
.zip file	mindaromaster Storage Account	https://mindaromaster.blob.core.windows.net/zip/lks.json (contains .zip link)
NuGet package	Mindaro-Dev NuGet feed	Microsoft.DevSpaces.CLI
VSCode extension	mindaromaster Storage Account	https://mindaromaster.blob.core.windows.net/vscode/LKS/mindaro-1.0.1.vsix

Staging

Preparation

TBD need git replacement

Release

Whenever changes are pushed to the staging branch, the Build and release pipelines build updated components and automatically release them into the Staging environment. No manual intervention is needed unless a pipeline fails.

After the releases complete, test to ensure that the new staging version of the VSCode extension can successfully download the correct staging build of client binaries (set BRIDGE_ENVIRONMENT=staging).

Component	Released to	Download
Service images	mindarostage Azure Container Registry	mindarostage.azurecr.io/routingmanager:latest mindarostage.azurecr.io/lpkremoteagent:latest mindarostage.azurecr.io/lpkrestorationjob:latest
.zip file	mindarostaging Storage Account	https://mindarostaging.blob.core.windows.net/zip/lks.json (contains .zip link)
VSCode extension	mindarostaging Storage Account	https://mindarostaging.blob.core.windows.net/vscode/LKS/mindaro-1.0.1.vsix

Production

Preparation

TBD need release plan for git

Snap staging into the production branch

TBD need plan for git

Release

Whenever changes are pushed to the production branch, the Build and release pipelines build updated components and create releases to deploy the changes them into the Production environment. The 'Prod' stage of each release must be manually approved.

After the releases complete, test to ensure that the new version of the VSCode extension installs and successfully downloads the new build of client binaries.

The team that owns the VS extension will receive a notification when a new version of the NuGet package is pushed, but it's a good idea to contanct them when a new a new package is available and coordinate its integration and release. The dev owner is David Negstad (danegsta@microsoft.com) and lead is Devin Breshears (devinb@microsoft.com).

Release	Component	Released to	Download
[Mindaro-Connect-Services](TBD need git replacement)	Service images	bridgetokubernetes Azure Container Registry	bridgetokubernetes.azurecr.io/routingmanager:latest bridgetokubernetes.azurecr.io/lpkremoteagent:latest bridgetokubernetes.azurecr.io/lpkrestorationjob:latest
Mindaro-Connect-Zip	.zip file	bridgetokubernetes Storage Account	https://bridgetokubernetes.blob.core.windows.net/zip/lks.json (contains .zip link)
Mindaro-Connect-VSCode	VSCode extension	Visual Studio Marketplace	https://marketplace.visualstudio.com/items?itemName=mindaro.mindaro

Hotfix

If an urgent issue is found in production, a targeted hotfix can be released without snapping branches or re-releasing all components.

1. Test the fix in the Dev and/or Staging environments to ensure it resolves the issue and doesn't introduce any new problems
2. Cherry-pick the change from the main or staging into the production branch
3. If the fix is in the client binaries:
   • Consider updating the CliMinVersion in Constants.ts to ensure that VSCode users get the new client binaries when their extension is updated
   • Also consider releasing a new NuGet package so the team that owns the VS extension can integrate the fix and release an update. Contact David Negstad (danegsta@microsoft.com) and Devin Breshears (devinb@microsoft.com) on the VS team to coordinate.
4. Approve Prod releases of only the impacted component(s) and ignore (or cancel) the others. If the change was confined to services (e.g. devhostagent, restorationjob, or routingmanager), no release is necessary because the image will be pushed by the Mindaro-Connect-Services build.

Appendix

Analysis and sanity builds

Confirm that these builds are completing successfully on the source branch before snapping, and on the target branch after snapping.

• [Mindaro-Connect-SecDevTools](TBD need git replacement)
• [Mindaro-Connect-SDL-Scan](TBD need git replacement)
• [Mindaro-Connect-SanityBuild](TBD need git replacement)
• [Mindaro-Connect-VSCode-SanityBuild](TBD need git replacement)

Prerequisites to snap

To force push (git push -f) into the staging and production branches, you'll need to define permissions for yourself on both. If you don't have permissions to define your permissions, Dan (daniv@microsoft.com) can grant you the necessary permissions.

1. Open https://dev.azure.com/DevDiv/DevDiv/_git/Mindaro-Connect/branches
2. On both the staging and production branches, open '...' > 'Branch security' and add an entry for your alias with Allow permissions for all actions
   • Note that your permissions to 'Bypass policies when pushing' and 'Force push' will be overridden to Deny by the Mindaro team policy EXCEPT when you temporarily relax Mindaro permissions during a snap

Notes

• We use git reset to snap into staging and production rather than git merge because over time with hotfixes, manual merge conflict resolution, and cherry-picking the branches tend to drift apart unless they're aligned with git reset. By resetting for every snap, there can be no unexpected differences lurking in the production branch.