Why would you deploy something to Azure from Jenkins, when there are perfectly adapted and way better options, would you ask? I have a perfectly valid set of reasons1. We’re gonna follow roughly similar same steps to the deployment from Codeship, and enhance them to use a staging slot and auto-swap on production to prevent service interruption.

We’re assuming you already configured your build to trigger adequately. We won’t cover the build and test itself, but just the deployment, neither are we going to cover thesimple case where where we just want to deploy to a given web app - for this refer to this post.

The mechanic is simple: create a staging slot, to which you deploy, then swap this slot with production. If you already setup your local git repository, start by disconnecting it from the main slot2.


Create a staging slot on your web app - clone configuration from your prod environment.

Add slot

Then open your staging slot by clicking on it, and setup the deployment using local git repository:

Setup deployment

Go to the settings and setup auto-swap with production:


When you push to master, the code is going to get deployed to the staging slot, then once the deployment script ran, staging will become production and vice-versa. Finally, pick the url to the git repository from the “Properties” blade3 of the staging slot, and update your deployment settings to use the staging url.

Do a minor change and observe what’s happening.

Deployment done


  1. The first of which being, “I want something now, I don’t have an alternative, and I don’t even want to start discussing using VSTS for deployment on Azure because SoC”. 

  2. If you don’t clean the build environment when building, you’ll also need to clean it so it doesn’t deploy to the former build url. 

  3. Deployment Credentials are the same as for the main repo. In fact they’re the same for the entire resource group.