February 12, 2010 at 8:33 am
The database team here manages instances of SQL with 5-6 shared databases on each. These contain things like customers, items, orders that several different application teams write code against (teams are not centrally located or controlled under the same managers).
My question is how do you manage builds to your test/production environments so that there is quality control and preferably automation built in?
Just looking for some ideas on how to improve - not much out there in this space...
Cheers
http://twitter.com/widba
http://widba.blogspot.com/
February 13, 2010 at 4:34 am
my experience over 16 odd years is that it only truly works where there is a QA dept who handle/store all the scripts and manage a controlled release process.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
February 13, 2010 at 6:52 am
Thanks - that would be an interesting use of QA. Our current structure really does not have QA in the loop when going to production or the build process, it might make them test better if they had feedback like the rest of us do.
Cheers
http://twitter.com/widba
http://widba.blogspot.com/
April 20, 2010 at 3:40 pm
You're right. There isn't a well defined method of promoting between dev/test/prod. Probably because it depends so much on team structure and discipline.
I build my releases from SourceSafe - I get anything changed since the last label then I label again. This forms the basis of my release. I then deploy this release to test and await feedback. I change this release (and relabel) if anything fails test. Once the testers pass a release, the release package goes to the implementation team.
There is a lot of manual work involved but I developed this tool to at least make the pushing of scripts to SQL Server easier: www.sqldart.com
I also have a script which gets the stuff from SourceSafe that has changed since the last label.
April 20, 2010 at 6:42 pm
Thanks - we are looking at a label like implementation to snap builds at certain points. We have lists of objects and their path in source and use the versions to make builds. Each team puts their list together for their build and amends it and gets it right - then our test build is official and we use the lists only - it has made things work - just nice to get peoples different thoughts on the subject. Any new way of doing it adds to the toolbox.
Cheers
http://twitter.com/widba
http://widba.blogspot.com/
April 20, 2010 at 9:49 pm
Two things here.
1. You need code control.
2. You need a process for building the release.
#2 has lots of options.
For #1, I don't think it needs to be a dedicated QA group, but it does need to be someone with an extremely firm hand to ensure that all releases go to QA and ONLY what is released to QA goes to production. So if issues are found in QA, you must roll back QA, re-release to QA, and then release to production.
This worked well for me as a production DBA, though I definitely had issues with management and developers at times forcing them to re-release to QA. Often what happens is there's a bug, a developer creates a fix, the fix is moved to QA and then appended to the release process. The problem there is that you now have two releases that occurred. If this happens 3 or 4 times, you can easily lose control.
April 21, 2010 at 7:06 am
Source is key - that is for sure.
I think the difficult part is in the QA/firm hand area. You mentioned the organizational pressures and they are very true here, developers making lots of mistakes and basically wanting to develop in the QA environment.
We are going to try an experiment here in the near future - with letting the development teams control their builds - but then forcing a documented build to the Test environment (3rd env in our case). This way the teams have the freedom to build to QA whenever they feel like it, and the QA and Dev teams can fight over the builds. Leaving the friendly DBAs to guard the Test system gates.
Our theory is you need to have one quality test of the build process before going to production. 2 would be preferable - but I guess we don't all work on space station software, so one should be good enough.
Cheers
http://twitter.com/widba
http://widba.blogspot.com/
April 21, 2010 at 11:26 am
Subversion is a great source control product, highly recommend it!
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply