How a change reaches production
“How is your .NET + Angular app deployed to production? Walk me through it.”
One build moves through four environments and two approvals, then a slot swap puts it live. Swapping back is the rollback.
See it
1/10You open a . One reviewer approves and builds and tests it. Only then can it merge.
In plain words
Code never goes straight from a laptop to customers. It goes through a , then builds one package, and that same package moves through DEV, , and , each a separate copy of the system with its own settings. Before production, someone at BMW FS must approve a (the weekly , or a faster route when it cannot wait). On release night it is deployed to a , checked, and swapped in. If it misbehaves, swapping back puts the old version live again in seconds.
- Every change starts as a : one reviewer who is not the author, a green build with tests, and a linked work item.
- builds once. The release pipeline promotes that same package DEV → → → PROD; only settings change, from and .
- Production needs an approved : for a normal release, a same-day OK for an , an only to stop harm now.
- In the we deploy to the , it, then swap. Rollback is swapping back, so database scripts must work with both versions.
- After the swap we watch (failure rate, response time) before closing the change.
What they ask next
Interviewers check that you can explain every line. Tap a question to open it.
What does the textbook say, and what really happens?
Textbook: every change gets full and cycles and waits for the weekly . Real life at a client like BMW FS: is often one or two days, a fix that cannot wait goes as an , and may not exist at all for smaller clients. The rule a senior keeps: shorten testing, never skip it, and always have a plan written in the .
Expedited change or : what is the difference?
An expedited change is a normal change approved faster, because waiting costs more: it is still tested, just in a shorter cycle, and two named people approve it the same day. An emergency change stops harm happening right now (a ): one or two people approve it, it may skip , and the reviews it afterwards. Calling a fix an emergency to dodge the is a red flag to clients.
Swapping back undoes the code. What about the database?
It does not undo the database. So migrations are written to work with both the old and the new code (add a column first, remove the old one in a later release). The script is generated with
dotnet ef migrations script --idempotent, reviewed, and run by the client's before the swap.What is different for the Angular portal?
ng buildruns once and the same files go to every environment. Settings such as the API address cannot live inenvironment.ts, because that is baked in at build time and would mean one build per environment; the portal reads a per-environmentconfig.jsonat start-up instead. A release copies the files; a redeploys the previous package. File names carry a hash, so browsers do not keep old code.And the Azure resources themselves?
In the textbook, infrastructure is code (Bicep or Terraform) in the same pipeline, with a what-if preview reviewed in the . At many clients a platform team owns it and you raise a ticket, and some settings were changed by hand in the portal. That drift is why a senior compares the and app settings between and PROD before release night.
Why not build separately for each environment?
Then tested a different build from the one that goes live. Building once and promoting the same package means what BMW FS signed off is exactly what customers get.
Traps
- Don't say
We build and deploy to each environment from our branch.SayWe build once and promote the same package; only the settings differ. - Don't say
Rollback means redeploying the old code.SayOn it is a back, seconds. The database is the hard part, so scripts work with both versions. - Don't say
We skipped because it was urgent.SayIt went as an with a shortened , approved by named people. Less testing, never none.
Copilot can draft the and the 's risk and text; a human checks both. Approvals stay human, and an AI agent never holds production deploy credentials: Replit's agent deleted a production database in Jul 2025 because it could reach it.