SQL Server Forums
Profile | Register | Active Topics | Members | Search | Forum FAQ
 
Register Now and get your question answered!
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 SQL Server 2008 Forums
 SQL Server Administration (2008)
 Putting DB objects in source control
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

shiftbit
Starting Member

USA
1 Posts

Posted - 03/05/2013 :  13:43:20  Show Profile  Reply with Quote
Ok, on a new project and there are several DB's involved, some with a few hundred procedures and tables in them. I want to put these objects in source control AND automate the change management into the production or live databases.

Anyone familiar with Red Gate source control product?
Ive seen an example of using DB Ghost and running it from a sql job.
This is kinda the approach I had in mind, but not sure if the Red Gate tool can handle this?
Anyone done something similar and care to share their notes?

Thanks in advance.

Now that I just typed that, I stumbled on the help page I was looking for (I think). Or at least it gets me closer

See this reference
http://www.red-gate.com/supportcenter/Content/SQL_Source_Control/help/3.1/SSC_deploying

Edited by - shiftbit on 03/05/2013 13:53:56

denis_the_thief
Aged Yak Warrior

Canada
593 Posts

Posted - 03/06/2013 :  13:21:47  Show Profile  Reply with Quote
I would see this as 2 separate issues: 1) Source Code Control 2) updating your live Databases.

I recommend some kind of source code control for anything involving coding (views, sps, functions). We use Source Safe. Although many consider Source Safe to be the worst and that may be true, some source code control is better than nothing. So many times this has helped us out. For example when making a patch, we need the full history of the changes of a Stored Procedures, often we need to ask a Developer why a specific line of code was added.

For updating your live Databases. I would be cautious with any type of automation. Usually if there is an error in the execution of a step, you want to look at that before the next steps are run. If a tool can stop on error then maybe it's a good idea.
Go to Top of Page

denis_the_thief
Aged Yak Warrior

Canada
593 Posts

Posted - 03/15/2013 :  16:13:07  Show Profile  Reply with Quote
quote:
Originally posted by denis_the_thief

For updating your live Databases. I would be cautious with any type of automation. Usually if there is an error in the execution of a step, you want to look at that before the next steps are run. If a tool can stop on error then maybe it's a good idea.



I am curious if anyone else can weigh in on this. Running migration scripts through automation. We can even have 100+ scripts to run in one upgrade. Does anyone have any support or lack of support with running migration scripts through some automated means?
Go to Top of Page

robvolk
Most Valuable Yak

USA
15676 Posts

Posted - 03/15/2013 :  16:30:25  Show Profile  Visit robvolk's Homepage  Reply with Quote
I would recommend against any kind of automated deployment to a production system, even if you have a completely identical deployment environment and thorough deployment testing processes (and you'd be crazy to even try it without these, IMHO). Some people have made it work, via continuous integration extended to continuous deployment, but they tend to be highly disciplined shops with bulletproof testing procedures (regression, QA, UAT, load, etc.). Fault tolerance is the key phrase here: any automation has to automatically handle and recover from errors.

Like the old saying, "If you have to ask how much it costs, you can't afford it", if you have to ask if automated deployment is a good idea, it probably isn't for your environment.
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
SQL Server Forums © 2000-2009 SQLTeam Publishing, LLC Go To Top Of Page
This page was generated in 0.06 seconds. Powered By: Snitz Forums 2000