Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

How do you do DB builds? Expand / Collapse
Author
Message
Posted Friday, February 12, 2010 8:33 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Sunday, July 13, 2014 5:53 PM
Points: 94, Visits: 575
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/
Post #864675
Posted Saturday, February 13, 2010 4:34 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, June 9, 2014 6:02 AM
Points: 2,674, Visits: 697
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.

The GrumpyOldDBA
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
Post #865070
Posted Saturday, February 13, 2010 6:52 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Sunday, July 13, 2014 5:53 PM
Points: 94, Visits: 575
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/
Post #865082
Posted Tuesday, April 20, 2010 3:40 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, November 18, 2013 3:26 AM
Points: 10, Visits: 37
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.




Post #907307
Posted Tuesday, April 20, 2010 6:42 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Sunday, July 13, 2014 5:53 PM
Points: 94, Visits: 575
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/
Post #907360
Posted Tuesday, April 20, 2010 9:49 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 6:20 PM
Points: 33,078, Visits: 15,192
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.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #907410
Posted Wednesday, April 21, 2010 7:06 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Sunday, July 13, 2014 5:53 PM
Points: 94, Visits: 575
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/
Post #907697
Posted Wednesday, April 21, 2010 11:26 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 7:43 AM
Points: 6,178, Visits: 13,323
Subversion is a great source control product, highly recommend it!

-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs"
Post #907967
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse