0
votes

I just stumbled across this blog post about deployment slots. I've been wondering for over a year how I could minimize downtime when pushing new versions of code into production...I never knew/realized what could be done with deployment slots.

So, I went ahead and started setting up my deployment slot, called "staging".

After creating the slot, I went to the site to see if everything worked. When the page loaded, it said the site was created, but nothing has been deployed. I realized I also need to set up my continuous deployment to the slot.

I then tied this staging slot to my master repo via BitBucket. Now the code is deployed and the site loads.

First question: now I have the regular production site loading from my master branch, as well as the staging version. Should the continuous deployment be taken off the regular production version? For example, if/when I merge to master branch, would it build and deploy to both sites, or is it smart enough to recognize a deployment slot, and only deploy to that one, and then wait for either the manual swap, or configure the AutoSwap to push the code to production?

Second question: on the staging slot, my site.min.css file is empty, therefore any of my css changes that are specific to my site are NOT loading. This makes it look horrible. Why isn't my css loading to the deployment slot?

Prod: http://www.wrestlestat.com Staging: http://wrestlestat-staging.azurewebsites.net

1

1 Answers

2
votes

If you have a staging slot then you don't need to configure CI for your production site. You need to configure CI from master to staging slot and do swap with production. For swaping I would advise on configuring auto swap.