How can we improve Azure SQL Database?

Support staging/production scenario as in Windows Azure

This could be done with the future cloning technique or perhaps a more sophisticated one?

79 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    anonymousanonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Mike TaberMike Taber shared a merged idea: Support a true Staging environment that applies transforms to production datat  ·   · 
    Raja K.Raja K. shared a merged idea: SQL Azure Beta Cluster  ·   · 

    3 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Shannon LowderShannon Lowder commented  ·   ·  Flag as inappropriate

        Yeah, the built-in db copy could be used to clone the db, just restore it to your db_staging like mxrss suggests. You could even use powershell to automate the restores with some work.

      • Chris SchallerChris Schaller commented  ·   ·  Flag as inappropriate

        I'm not sure how much of this is "Azure's" responsibility.
        It is not the platform's role to identify all of the services that your solution might be using, nor are you confined to only consuming services in Azure.

        Firstly, there are common staging vs production paradigms that we as developers have been implementing long before Azure, I have to ask:

        Why are you treating your deployment to Azure differently to your normal in-house or client test vs live environments.

        Secondly, Visual Studio has provided awesome support for deployment to staging vs production.
        Our App uses two separate databases, multiple services outside of azure and 3 roles within.
        In our Visual Studio solution, we have the two Azure deployment profiles, one for staging, one for production, we then have two solution configurations... you may have heard of them, Debug and Release.

        We have two rules in-house. Staging deployments MUST be debug builds, Production deployments MUST be release builds. The Deployment profiles handle this for us so it's not something that you need to be overly aware of.

        We toyed with the idea of changing the solution configuration names to Staging and Production but the name is arbitrary.

        We use mainly web.config transformations (visit http://go.microsoft.com/fwlink/?LinkId=125889) to handle the fact that settings need to be changed between the two environments and some compiler directives.

        To Handle our Azure DB changes we could use DAT packs, however we have an in-house solution were the service roles detect changes and verify DB schema on version upgrades, as this is the solution we have been using for many years now, it all still functions the same in Azure.

        Because we integrate with a number of on-premise services, there is no way that Azure could automatically migrate or indeed affect the state of these services. So either way we would have to manage this ourselves, as you would expect, however the web.config transformations really are instrumental in managing our service proxy configuration.

      • mxrssmxrss commented  ·   ·  Flag as inappropriate

        Cant this be done by either

        1) Creating a new DB Server
        2) Creating a copy of the databases like stagging_db

      Feedback and Knowledge Base