Connection Strings are replaced when performing Azure Web Site staging Swap

Question

(1) we have a web application running on Azure Web Site using Sql Server (Web Edition). The application includes two connection strings:

• DefaultConnection - normal connection string, in the form of Server=tcp:{my-sql-server}.database.windows.net,1433;Database=...).

• EFConnection - Entity framework connection string. Since im using the EF designer (and loving it) i need to use a connection string in the form of metadata=res://*/Models.EDM...

(2) I've placed the connection strings in the web.config; this is the only way the "metadata..." (EF) connection string was accepted (when tried to enter these connection strings in the Azure web site's control panel, i got all kind of strange errors).

Everything works great.

(3) Next, I have added a staging slot to our web site to perform staged development, as described in Staged Deployment on Microsoft Azure Web Sites

The staged site works fine. I've created for it a different Sql Server, and set its connection string in the same manner as in the production site (ie. in the web.config). I handle the different web.config using web.config Transformations. (i have another 2 transformations - for development/debug and for local deployments/release)

---

The problem: now that i have a production + staging site, i try to do swap. The swap works great, and any changes introduced to the staging site are swapped to the production.

However, the swap also takes the connection strings from the staging site, connecting the production to the staging database.

*Is this a known bug? is there a work-around? (for now i am required to do direct deployment to the production site once QA tested the staged site - this means downtime for our site, and quiet defeats the purpose of this whole exercise)

Answer 1

App settings and connection strings are not sticky to the slot and will remain with the website when swapped but we can configure selected app settings and connection strings to become sticky to the slot using a PowerShell command (not yet supported by the Azure portal).

Use this command in Azure PowerShell to set 2 app settings as sticky to the slot:

/* If you have one config */
Set-AzureWebsite -Name mysite -SlotStickyAppSettingNames @("myslot")

/* If you have more than one */
Set-AzureWebsite -Name mysite -SlotStickyAppSettingNames @("myslot", "myslot2")

And this command to set 2 connection strings as sticky to the slot (follows the same described principles above):

Set-AzureWebsite -Name mysite -SlotStickyConnectionStringNames @("myconn", "myconn2")

Sticky to the slot configuration is website-wide configuration and affects all slots in that website.

EDIT:

As noted by Jeff Treuting in one the comments below, now the new portal has a "Slot setting" checkbox that you can select going to:

"Web Apps" -> choose your web app -> "Settings" -> "Application Settings".

Answer 2

The Staging environment is a production swapping mode that allows you to perform an upgrade of your website compeltely before you swap it with the current production system. It also provides a rollback mechanism in case there is an issue with your upgrade.

Perhaps the word Staging is a little misleading for companies that use this term to represent a QA environment as close to production as possible. In Microsoft Azure, the Staging environment is a pre-production concept that allows you to pre-configure and test an upgrade of your website.

QA environments should have their own environments.

Answer 3

The deployment slots feature for Azure Websites allows validating a version of your site with full content and configuration updates on the target platform before directing customer traffic to this version. The expectation is that a deployment slot would be fully configured in the desired target format before performing a swap. The swap operation does not apply transformations to the source deployment slot, it seamlessly redirects web traffic.

One idea to simplify the workflow in terms of validation and pre-swap updates would be using app settings for EF connection strings.

Answer 4

so we should use azure "staging" as another step in the deployment - a method used for assuring immediate deployment, without site downtime?

in that case i can still use it as a qa environment, and reconfigure before swapping with prodcution.

Answer 5

FWIW, you can save the EF connection string in the Azure portal by (a) copying and pasting the entire string BETWEEN the quotation marks, (b) replacing the HTML entity-modified quote mark around the inner connection string with actual double quotes, and (c) selecting "Custom" for DB type in the Azure console.