I have been using Azure for some time for some different website I have been working on. Using visual Studio to do the publish and Azure holds the website and the sql. My question is this: How do I manage to publish to the development site and the production site? I have looked around on the web and have not found what I have been looking for so far.
If I choose the publish profile for my production site, and publish via visual studio, how do I control that the website uses the correct production db? In the web.config of the site is currently the connectionstring for the development sql db.
I dont want to sit and change the connection string every time I want to publish to the production site. There must be an easier way to do this?
I imagine that when I sattisfied with the looks of the website on the development site, I will move it to the production site. But how is this handled?
Hope you can help or send me in the right direction.
Using the Connection Strings in the Azure Portal, specify the production connection string in the production site configuration and the dev connection string in the dev site configuration.
these connection strings are injected into your .NET configuration connectionStrings settings at runtime, overriding existing entries where the key equals the linked database name.
https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure/
Related
Im having a bit of difficulties trying to understand how to handle the connection string in my web site. The web site is hosted in Azure. The Web App in Azure has a Linked Resource to a DB also in Azure. This works fine now and all is great... But what when I need to deploy my website to my production site? During development im using a dev website and a dev db in Azure. So therefore my connectionstring is also named differently for each environment. The name of the connection string is dbname_dev. This is the name of the Linked Resource so I guess this is also the name of the connection string.
So I could just add an empty connection string with that name and then use
connString =
Environment.GetEnvironmentVariable("PREFIX_myConnStringName");
go retrieve the connectin string and Azure will make sure to replace i during runtime.
But what happens when the site needs to be moved to the production site and db? Then the db is named differently and then the Linked Resource name is name differently. I would then get into trouble because my code above would still have the name of the Linked Resource that I used in the dev environment.
I hope I made myself clear :) I know its at bit hard to understand.. :)
Instead of naming the connection string in your web.config you can set the connection string from your app's settings sections in the portal. Those settings will stay in the same slot.
This way when you swap your dev and production slots, your prod slot will get the new bits but will keep the old (prod) connection string setting.
You can find more details here: http://blog.amitapple.com/post/2014/11/azure-websites-slots
I've recently started using Microsoft Azure and Visual Studio Team Services.
We use VS Team Services for cloud storage of our source repositories in TFS.
Continous deployment is configured to build and deploy on every commit.
As of now, our development environment is public and can be visited by anyone (published to azurewebsites.net)
However, we would like our development environment to be private and not accessible using a userfriendly url. We could implement some authorization on the web site to prevent others seeing our development site, but there must be another way.
There are ways to accomplish this using deployment slots in a staging area (will give me some guid url), but it doesn't seem right.
Is there any built in support to Azure (or Visual Studio Team Services) to accomplish this?
You could leverage domain and / or IP address restrictions to limit who can connect into your host. See: http://azure.microsoft.com/blog/2013/12/09/ip-and-domain-restrictions-for-windows-azure-web-sites/.
(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)
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".
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.
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.
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.
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.
I am looking at migrating a dotnetnuke website to Azure. I need both staging and production versions of the site to be running.
I have looked at using Azure Websites, but at the moment there is no support for SSL on custom domains so this can't be used for the production website. I have migrated the staging site to an Azure Website and now have numerous options for publishing updates (ftp, git, using web matrix).
Due to the constraints of Azure Websites, I used the DNN Accelerator to create a cloud service for the production environment. This set up will allow me to have control over IIS and therefore manage SSL certificates (I think).
The problem I have with this is there does not seem to be any publishing options. The only way I can publish is by connecting to the Azure instance via RDP and then copying the website files onto the files system.
Are there any other ways of publishing? I have looked at converting the website to a WAP, but I believe this has implications when it comes to updating to new DNN versions.
You should never publish your application through RDP since these changes are non-persistent (meaning what you published might disappear after a hardware failure / ...). Adding new instances would also mean that these instances don't have the files you published before.
I suggest you start by looking at the DotNetNuke Azure Accelerator first. If this doesn't fit your needs you might always try to build something yourself, but if you want to say with a regular website and not a web application I wouldn't count on Visual Studio support. In that case you might want to look at creating a package from the command line and using startup scripts to add your website in IIS.
Sounds like you need to use a Start-up task to install the files in the correct place for a Web Role (Cloud Service) Smarx has a nice overview here, MSDN has a wealth of info too http://blog.smarx.com/posts/introduction-to-windows-azure-startup-tasks
Another option is IAAS for Azure with a persisted VM, more work mind you, Cloud Service would be the most efficient and correct solution...
I have a single web project that I want deploy in Azure.
I want to create one IIS web site per country and I want to be able to deploy each web site independently (not all of them at a time). How to do this?
Well,
you have two options:
Use Windows Azure WebSites to host your websites
Use Windows Azure Accelerator for WebRoles or your own project similar to that approach.
However you have to note that the second option is a project that is no longer being supported due to avialability of Azure Websites. With Azure Websites, you can have almost everything you get with the Accelerator. You can host your websites on a dedicated instances, and manage them individually. You can update/deploy your website data via FTP/GIT/TFS/WebDeploy, whichever method you are most happy with. The only downside of websites which I see, is the lack of Startup Tasks and the ability to customize your environment (Windows, IIS settings, etc).
When you have set up your Azure account you can go the the web sites section and start the construction of your Azure web spaces, the interface in the preview is very straight forward to use and intuitive.
For deployment using the publish command in from Visual Studio 2012 (which I found the easiest) here are the steps you will need to undertake:
For each of your countries you will need to set up the web site
in azure.
Then for each of those web sites you have created go
to their dashboard page and download the publish profile settings.
It is these settings that you can import into you Visual Studio
solution by selecting the publish command and browsing for the
settings profile file you downloaded and importing it.
Then in future when
you right click on the web site in your solution and select publish
it will publish to your web site in Azure.
I have created a fictional website for Spain below is the link you will need in order to initiate a publish from Visual Studio.
------------ EDIT -------------
For Visual Studio 2010 I met some difficulties trying to publish, in fact the publish profile you can download was not importable to Visual Studio 2010, well at least I could not figure it out.
Instead I created a deployment user by clicking on the 'Reset Deployment Credentials' link on the Azure dashboard (see the link in the image), created the user and then published via FTP from Visual Studio 2010.
What I would like to flag up is the maintenance issue of having one site for each country rather than one site with Localization, (if it is a language issue). A small change multiplied just 20 times for 20 different countries becomes a larger task and if you have lots of little changes it soon becomes a large task to maintain them all.