Anyone using Azure deployment slots with Kentico?

Depends on what you're doing. If you're simply testing code to ensure the code functions and builds then no need to deal with the connection string/database.

If you're doing a whole other deployment, then you'd typically have the new slot along with a copy of that production database running side by side. The main website and the slot would have a connection string which are "slot specific". As long as you DO NOT have this box checked on your main website and your slot you're good. Once you perform the actions you need on the slot, you simply click swap and your site swaps out. Since you do not have that box checked as slot specific, the connection string and all settings for the slot get moved over to production.

It's really a pretty awesome way to deploy any updates or upgrades pretty easy.

Thanks Brenden. There's one thing I'm still not sure about. Let's say we have two deployment slots, A & B. A is current production, and B is staging, connected to a point-in-time copy of the production database. The week prior to the rollout, we do our code deployment and all our testing in B. When we go live, we swap B with A, with B now connected to the production database. If there are any database updates or changes that are part of the new version, they would have been made on the staging database, not the production one. How would you handle getting those into the production database? Hopefully that makes sense.

First off, never use a slot as your "staging", or "development" environment. A slot utilizes the resources from the primary web app so not really a good idea to have your "development" site utilizing the same resources as your production site. I know I'll get some pushback on this but slots should really only be used for deployment of new code and getting your site warmed up prior to swapping slots out.

To answer your question, typically what we do for upgrades and hotfixes is to run test of the upgrade on a backup of production. Get all the kinks worked out then run it again on production later when we're ready to go live. By that time you'll have the procedure figured out and hopefully all the gotcha's worked out.

This typically means you'd take a backup of the database on production when you're ready to run the upgrade. There may be some time, depending on how many upgrades you're running and amount of traffic on your site, where you may miss some data (form submissions, contact's activity tracking, etc.) but that should be pretty minor all things considering. Run the upgrade on your copy of the database, then swap the slots out.

Thanks. I may be using the wrong term. In our environment, staging would be the slot where the new code is deployed to right before the switch to prod. We run a quick test to make sure that nothing broke or was missed during the Octopus deployment. We don't do any load or other heavy testing there.