6. Deployment & Branching

The branch → environment map

Each long-lived branch is an environment:

Branch	Environment
master	prod
develop	dev
qa	qa
stage	stage

Deploys run on Azure Kubernetes Service (AKS) via GitHub Actions + Helm. Merging into develop auto-deploys to dev. Changes then get promoted upward (qa → stage → master) via PRs. Prod deploys are a manual trigger (workflow_dispatch) in most services — merging to master does not ship by itself.

The normal flow

Two rules that are not optional

Do not break the branch model

1. Never commit directly to an env branch. develop, qa, stage, master all take changes only via a feature branch + PR.

2. Never base a new branch off an env branch. Base only off master, or off an existing feature branch that was itself cut from master.

Why it matters: an env branch carries every in-flight change sitting on that environment. Cut a branch from it and you drag all of that unrelated work into yours — and you poison the branch model, because you'd then have to merge the env branch into downstream branches forever. Always start from master.

The trap: if the code you need to change only exists on an env branch (a feature not yet on master), still don't branch off the env branch — find the original feature branch that introduced it and base off that.

Config changes ≠ code deploys

A lot of "changes" here don't touch code at all. Per-environment values live in the Spring Cloud Config Server (see page 3). Changing one is: edit the value → restart the pod. No build, no release. Reach for a code deploy only when you're actually changing code.