Deployment Environments
The internal VMs each branch actually deploys to, and how production ships.
Deployment Environments
mcm-devops's build-publish-and-deploy.yml is what every other repo's build_push.yml calls (via its trigger-devops job) after building and publishing an image. It owns the actual routing from branch → environment.
Internal environments
| Branch / trigger | Deploys to | How |
|---|---|---|
develop | Develop VM | Automatic on push |
workflow_dispatch with promote_to_develop2=true | Develop2 VM | Manual — used after a developer has validated a build on the Develop VM, as a pre-QA staging step |
qa | QA VM | Automatic on push |
Any other branch (feat/*, fix/*, etc.) | Feature VM (single shared instance) | Automatic on push, if that repo's CI trigger list includes the branch |
main | (none — see below) | — |
Production doesn't auto-deploy anywhere internally
This is easy to miss reading the workflow casually: setup-deploy explicitly sets should_deploy=false whenever the branch is main (or when bundling images). So a main push builds the image, tags it X.Y.Z, publishes it to Nexus, cuts a GitHub Release, and packages mcm_artifacts_<version>.tar.gz — but there is no SSH auto-deploy step that ever runs for main, even though MAIN_VM_* secrets and a main branch case exist further down in the same workflow. Production, in the current pipeline, means "customer or Ops runs install.sh (fresh) or upgrade.sh (existing) against the published artifact" — the same model used for every customer install, not a RevDau-hosted environment that gets pushed to automatically.
Why this matters for release/<minor> branches
The per-repo build_push.yml push trigger and mcm-devops's setup-deploy routing only explicitly recognize develop, qa, and main today. A release/1.1 push matches none of them, which has two consequences:
- No repo's CI fires automatically for a
release/1.1push — no build, no tag, no GitHub Release — since the trigger list itself doesn't include it. - If that trigger list were extended to include it,
mcm-devops's routing would currently fall through to the generic Feature VM (the same catch-all shared by every ad hocfeat/*/fix/*branch) — not an appropriate place to validate a real customer hotfix.
Both need a small, deliberate CI change before the hotfix flow in the next page can run without manual intervention. See Hotfix / Patch Release Strategy for what that change is and what happens without it.