Managed Develop & Stage environments with a shared database model
Steveiwonder
Posts: 3 New member
Hi All,
We have a simple setup in the way we work which is as follows.
We have two environments, develop and stage, all our work is done on develop until we are ready to start a release/test. We branch from "develop" to "release/release-1.0" (git).
In SQL Source control both the develop and stage databases are linked to a source control folder (the same one locally). During testing we will fix any bugs on the stage database and commit them to "release/release-1.0". Once a release has been signed off we are ready to move any bug fixes from the ""release/release-1.0" branch back to "develop" the process falls down. We merge those changes from "release/release-1.0" to "develop" which is fine, but getting them applied to the develop database, seems well clunky. We have to generate a script (using compare) to perform the upgrade and then manually apply it, is this the best way? or are we doing source control for databases incorrectly?
Thanks
We have a simple setup in the way we work which is as follows.
We have two environments, develop and stage, all our work is done on develop until we are ready to start a release/test. We branch from "develop" to "release/release-1.0" (git).
In SQL Source control both the develop and stage databases are linked to a source control folder (the same one locally). During testing we will fix any bugs on the stage database and commit them to "release/release-1.0". Once a release has been signed off we are ready to move any bug fixes from the ""release/release-1.0" branch back to "develop" the process falls down. We merge those changes from "release/release-1.0" to "develop" which is fine, but getting them applied to the develop database, seems well clunky. We have to generate a script (using compare) to perform the upgrade and then manually apply it, is this the best way? or are we doing source control for databases incorrectly?
Thanks
Tagged:
Best Answers
-
AlexYates Posts: 264 Rose Gold 2Given that you are using the shared model that's probably the best you can do.
However, I would highly recommend that you ditch the shared model and move to the dedicated model. Trying to use a shared development database with a distributed source control system is simply a contradiction. You will spend more time fighting the tools than benefiting from them.
I appreciate that decision might be out of your control, but perhaps sharing this blog post with whoever has influence over the decision might be a good starting point:
http://workingwithdevs.com/shared-vs-dedicated/Alex Yates
DevOps Mentor and Coach
Director of DLM Consultants
Creator of Speaking Mentors
Microsoft Data Platform MVP
Friend of Redgate
Twitter / LinkedIn -
AlexYates Posts: 264 Rose Gold 2One thing you could do is select the dedicated option even though you are using shared. For various complicated technical reasons it will probably work fine. In order to explain that it might be worth actually scheduling a skype call to talk through it.
However, it's ugly and smelly and you should just move to the dedicated model.Alex Yates
DevOps Mentor and Coach
Director of DLM Consultants
Creator of Speaking Mentors
Microsoft Data Platform MVP
Friend of Redgate
Twitter / LinkedIn