Hello jbassking-7863,
I'm provide my own experience with 2 scenarios that could help you.
The first uses two VMs in for production and one for QA (Each Dev has it own private VM). We use load balancer to keep the APIs always on, so when we stop our ASP.NET Core microservices in one machine to update, the balancer redirects the calls to the other machine. To speed-up the process, each machine as 2 environments, so we first deploy in the secondary environment and run some tests to make sure everything will run smoothly, the stop the services in the first environment and promote the second one as primary. We keep the environment one with the previous version so in case of a rollback we have everything set up.
The second approach, cheaper one, is having the QA and production VMs working as two environments. So, when we updated one machine with a new version, it first becomes the QA environment. When we are ready to go, we switch the proxy to redirection external requests to this machine. The, one that was working as the production stays in with previous version for shortime, then we update it with the new version and it free to be used as QA.
There also azure features that helps to promote apps easily. Take a look
https://zcusa.951200.xyz/en-us/azure/app-service/deploy-staging-slots
Any questions, let me know.
Kind regards,
marionzr