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.
2. 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.
3. 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.
Every time i deploy role to staging environment, it receives new link based on deployment id. Please change the link to be the same every time. I have 3 web applications in a role and i cannot create persistent test domains assigned to staging environment to test application after deployment.
Good feedback. No plans in this area, yet.
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!
The easy way to deal with this is not to use the staging deployments for the services. Set up a new service for the staging version of each production service, and name them accordingly. For example, the production service might be TheService, and the one used for staging might be stTheService. This way, you always know the URLs. If you use VIP swaps to put your new versions in production, this won't work. Otherwise, it works perfectly.