May 20, 2010 at 6:04 pm
Hello,
I am seeking input on consolidating Views, SP's, UDF's, etc. to a single location. We have several databases that are duplicated for testing. We then of course have several replications of the same objects. So I was theorizing that it might be nice to let everyone have their little sandbox (data sandox) but only one tool shed (sp's, views, udf's, etc).
Thoughts, articles, input greatly apprecited.
JB
May 22, 2010 at 4:25 pm
In a properly organized three tier environment I expect to see as many as four different versions of an object.
1- In development. Checked-out object that is in development process under the control of a developer. This version of the object is expected to be sitting on the development environment, most probably in the developer's personal sand-box.
2- Development consolidated. Checked-in object that sitting in the development environment - nobody is touching it. This version is candidate for code drop into Test environment.
3- Test. Version of the object currently in the testing environment. This version is candidate for code drop into Production environment.
4- Production. Approved version of the code running in production.
I know there are particular cases where organizations add other environments but as a rule of thumbs in general you will find as many as four versions of the code.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.May 22, 2010 at 7:34 pm
Yes agreed. Problem is that it is all one one machine for dev, test, qa. Then it goes to prop on a different machine. They aren't even virtual machines. One machine stepping all over itself.
May 23, 2010 at 4:09 pm
nfs_john (5/22/2010)
Yes agreed. Problem is that it is all one one machine for dev, test, qa. Then it goes to prop on a different machine. They aren't even virtual machines. One machine stepping all over itself.
Not a problem at all.
I would install three SQL Server instances in box A... Dev, Test and QA and one SQL Server instance in box B... Production.
OR
I would create three databases... Dev, Test and QA in Box A and one SQL Server instance in box B... Production.
Either one would solve the issue.
No reason not to have appropriate version control no matter budget constraints.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.May 24, 2010 at 6:16 am
I'm with Paul, obviously it would be better to have multiple machines, but if you can't, multiple instances will at least simulate the results. This way you avoid the issue of having databases named MyDbDev, MyDbQA, MyDbStaging, and instead focus on a single set of code and a logical and controlled deployment mechanism so that you can know exactly what's going into production.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply