My company provides the AVACloud webservice as a SaaS offering. It's used to integrate tendering workflows for the German GAEB standard in my customers' apps. In fact, it's also used to power the free GAEB Converter here on this blog.
When running software as a service, it's mandatory that you have no downtime - this means for deployment scenarios, you can't afford to shut down your app, update it and slowly restart it. In fact, even warmup times in the range of 10 to 20 seconds are sometimes considered service interruptions, and they certainly don't make your service look professional and your customers happy!

Traditionally, you'd host multiple instances of your app with a central load balancer in front of it. When you update the app, you drain single instances until they have no more open connections, update them and repeat this process until all your nodes are at the latest version. This works fine, but is often a bit tedious to manage, especially from a DevOps perspective. Luckily, Azure App Service has the concept of deployment slots built in. You're only managing a single site, deploy to a staging slot, wait for it to warm up and then seamlessly swap it with the production instance. This can even be done automatically, so all you have to do is deploy to your staging slot and you're good to go.

However, sometimes you want to do some integration tests after deployment to ensure that the site works correctly, so you can't use the auto swap feature. In the following snippet, I'll show you how to use the Microsoft.Azure.Management.Fluent package to manage your App Services via C#.

To ensure that the app is healthy and working as expected, I'm doing a simple check on the https://avacloud-api.dangl-it.com/status endpoint. The app would report an unhealthy status if anything's not right. In your real life scenario, you might do a bit more than checking a single http response.

Tip: If disaster strikes, keep calm and remember that with deployment slots in Azure, you're just one single action away from doing a rollback to your latest working versions!

To set this up, you need to create a service principal in Azure with access rights to your App Service instance. Just follow the official docs, they're describing it in great detail. Just remember to follow best security practices and only allow access to a single App Service, not your whole subscription!

If you're interested how to do more DevOps & build automation directly with C#, have a look at the introduction for NUKE.

Happy swapping!