We are running a lot of our API endpoints and websites running node.js hosted on Windows Azure as Azure WebSites. A while back Microsoft introduced a pretty nifty feature called deployment slots.

Deployment slots – what are they

First of a little caveat: you have to be in standard mode to use the feature, free mode woun’t fly. So let’s say you create an Azure website. From that website you can then create one or many deployment slots. These slots are like a copy of the original site but with its on config and (in our case) local git repo.

Let’s go!

Navigate to the dashboard tab of the website and locate the Add new deployment slot

Give th deployment slot a nice name.

And badabing you have your deployment slot. You can see it in the portal if you hit the little expander arrow to fold it out:

Or by using the command line tools (preferably powershell if you’re on windows, I’m on mac now so I use the cross-platform tools) and there you can see the deployment slot as well using the “azure site list” command (the first time using the tools you have to do a pubSettings-file dance).

We got a deployment slot – now what?

So what we usally do is to make sure the slot (stage in my example) has a local repository. In our case we use git.

Then set up your deploy to production push to push to that local repo on the deployment slot. We use TeamCity and have set it up so it pushes to the stage slots every production build.

Then you can surf, connect your api-client or whatever to the stage url (api-web-stage.azurewebsites.net in my example) and test it out and make sure it all works.

Config

Each slot has it’s own version of the config such as app settings. This is awesome when you want to introduce some new config of change an existing value and make sure it works in production-stage before you deploy it. When you create a deployment slot you can chose to copy the config from the original website but after that they are detatced from each other.

So config for api-web (production)

And config for the api-web-stage (the slot)

Let’s do the same thing using the cross platform command line tools. “azure site appsettings list api-web”

And to view the slot by using the —slot parameter: ”azure site appsettings list —slot stage api-web”

Awesome feature but bare in mind, it’s entierly up to you to keep the configs in sync!
A little example. You introduce a new database and add it’s connection-string to the config of the stage-slot. All is fine and you swap the stage slot into production. Then you discover a small spelling error. You decide to roll forward so you fix it, deploy to the stage slot and swap that out to production. What just happened? You just swapped back the old config, missing the new connection string, into production with the code that expects it. So keep your config in sync :).

The swap

So, we have created our deployment slot, added a repo, added conifg and pushed our latest code to the stage slot. Now what?

I touched the subject above. Then we do a undramatic swap. You can find this button in the portal.

Or you could use the command line tools once again.

But wait what happened? I didn’t work did it! So after digging around the source on github for a while i realized I was running azure-cli 0.8.3 and I updated it to 0.8.5 (using nom update -g) and viola “azure site swap api-web stage” works!

Learnings

Working with deployment slots for a little while we’ve learnt a few things that might be of balue to others.

Local repositories

First I only created a local repository for the stage-slot, the thought being that we would never deploy to the production slot. The thing that bugged me big time with that solution was that I could not see which deployment (git checkin / sha) that was running i production. I had to look in the stage slot to see which deployment was running there and not in production. So we added a local repository to the production slot just to get visibility.

DNS for stage

I found it nice to put upp DNS entries for the stageing slot as well. That’s of course only applicable if you’re running on a custom domain. So for www.mysite.com (production slot) I put up stage.mysite.com (stage slot) for easy testing an communication with the rest of the company.

Summary

All-n-all I gotta give deployment slots two thumbs up! It’s a really neat feature for drama-less deployments and rollbacks if something breaks.