Azure WebJobs and Deployment Slots

Azure websites deployment slots are not an easy concept to understand, together with WebJobs it gets a little bit more difficult.

I suggest reading the following post to get a better understanding on deployment slots - http://blog.amitapple.com/post/2014/11/azure-websites-slots/ (including the comments section for useful information)

To get a better understanding on how WebJobs work and deployed see this post - http://blog.amitapple.com/post/74215124623/deploy-azure-webjobs/

It is important to understand that:

1. When swapping deployment slots you actually swap the content/files of the website between the 2 slots.
2. WebJobs are part of the website content.

So when you swap the slot you actually swap the website files including the WebJob.

Note it is a bad practice to deploy a WebJob directly and not as part of your website files/repository, this is probably the cause of issues you are having.

To prevent WebJobs from running on the staging slot you can add an app setting called WEBJOBS_STOPPED and set it to 1 (in the azure portal). (source). Make sure this app setting is sticky to the slot otherwise it'll propagate to the production slot.

It is possible to have a single production database shared by staging and production Azure App Service slots, and still having zero-downtime deployments.

To do this, you need to ensure that all your migrations are backwards compatible, such that the current and new versions of the web app can run simultaneously with the same database. This means you can deploy to the staging slot, perform your smoke tests against the production database, then swap the staging slot for the production slot.

Some rules that allow this to work:

• New columns should be nullable or have a default value set
• Columns cannot be dropped
• Columns cannot be renamed

When you do need to make a destructive changes, such as dropping a column, you need to have 2 releases:

1. A release that removes the dependency from the web app
2. A release that performs the change to the database schema

This sounds like a pain, but in practice you probably won't find yourself making destructive changes that often.