Pick a DNS name for Staging
After migrating a couple of sites to Azure the one request I have is “I want to choose my staging environment domain name (e.g. myApp.cloudapp.net)”.
I need this for several reasons:
1. SSL – The sites we deploy have SSL certificates and I want to be able to cover my staging site with a multiple domain (UUC) certificate.
WCF – If I have WCF services as part of my deployment, I do not know their URL (generated GUID) until after I deploy. I would like to know the WCF URLs in advance so my configuration does not have to change each time. Right now I have to deploy my WCFs separate from my other services, get the URL, then update my other deployments to this URL and then publish these services.
My test users need to know the test site. Each time now I have to let them know what the URL. I explain to them it is dynamically generated, but they keep asking why. I have to tell them to ignore certificate errors which is not a good habit for users to get into.
Good feedback. No plans in this area, yet.
This feature was first requested more than four years ago, and is one of the most requested new features. So much for "customer focus".
Ashish Jain commented
This feature is really useful and helpful, and will remove a lot of inconvenience for our workflows. --Ashish, ASG/AI&R
We run a SAAS solution, so a single application will listen to a lot of domains. In order to smoke test the application deployed in staging we now need to change al lot of DNS records (CNAME staging.ourapplication.com to for instance 531cssse8459298cd392818df3f86.cloudapp.net) and wait for distibution. Having a fixed DNS name for staging would fix this.
Every month we deploy a new version of our cloud service. We have a quite a large number of clusters of instances spanning the globe.
When switching we have to leave staging and production instances running for a week in case we need to swap back for some unforseen issue. It is very costly to run two copies of our entire cluster during this time so after a week we delete the staging environment.
This then creates a problem for the next release because we have an automated test suite that tests the production and staging environments before deployment. As the staging environment locations have all changed to new guids our test suit has to be updated all over again, introducing the chance of human error.. which we'd like to eliminate. A DNS name or fixed name like the webapp service does for staging slots would solve this. or allow us to shut down the staging environments and pay for just storage while we are not computing.
Alan Parr commented
The staging environments for websites have behaviour that would seem to fit this use case.
Could the websites implementation be ported over to Cloud Services? Would that be less work than reimplementing the feature from scratch?
Michael Paterson commented
Oh yes! I'm struggling with this right now.
Sebastiaan Molleman commented
I really hope someone will re-evaluate this idea since August 2013
Jurjen Ladenius commented
Jason's idea would be great. Automatic staging naming based on the service name.
Steve Cole commented
We use a multi-tenancy website. In order to check our websites (all within a single web role) on staging, we need to be able to visit the sites using real domain names that have preconfigured DNS entries. Without a consistent IP or site URL we are unable to do this.
Paul Turner commented
The generated GUID also poses a problem for exposing a static FederationMetadata.xml file, since you don't know the URLs required until after the deployment. It would be nice to just use "staging.myApp.cloudapp.net" as a predictable hostname.
@Robin - VIP swapping is a very important feature... I wouldn't even consider that because sites would have downtime... there's a reason why there is staging and production.
I've even tried to write a onstart command to rewrite my web.config to deal with dns entries on my web.config... unfortunately same problem as here, it uses a random user to startup the role vs network service... if network service was the startup user, this could be mitigated by running a startup script to change the permissions for web.config, and then updating those values based upon data given back from the webrole itself... and dynamically creating those based upon what environment it detects (staging/production)....
I have created a new request to offer a setting to allow for network service to be the designated user for role startup: http://www.mygreatwindowsazureidea.com/forums/34192-windows-azure-feature-voting/suggestions/3100745-start-webroles-as-network-service-instead-of-rando
What @Jason recommend is so far the best idea. We often delete our staging environments when we don't use them, so with every deployment we get issued a new GUID... Then change DNS's, even with a short TTL on the DNS it's time consuming... We all know developers don't like to wait for stuff.
They could just use staging.[Choosen DNS Name].cloudapp.net instead of using a guid
Derek Gabriel commented
I don't have any problem using a cname such as beta.xxxx.com - the GUID doesn't change if you push updates for changes, only if you completely redeploy. And then it's still not a big deal, because I use a TTL of 5 minutes on the beta dns records, so I can just pop into DNS and change the VIP address. I much prefer not having the available name pool reduced by beta and test apps. The system works great as it is.
This is especially needed if you run multiple websites within the same WebRole. You can't visit the staging website without having to map a CNAME to the newly created guid url. Very annoying!
Marcel Meijer commented
This is realy necessary!