Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
shiftbit
Starting Member
1 Post |
 Posted - 2013-03-05 : 13:43:20
|
| 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 closerSee this referencehttp://www.red-gate.com/supportcenter/Content/SQL_Source_Control/help/3.1/SSC_deploying |
|
|
denis_the_thief
Aged Yak Warrior
596 Posts |
Posted - 2013-03-06 : 13:21:47
|
| 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. |
 |
|
|
denis_the_thief
Aged Yak Warrior
596 Posts |
Posted - 2013-03-15 : 16:13:07
|
quote:
Originally posted by denis_the_thiefFor 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? |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2013-03-15 : 16:30:25
|
| 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. |
|
|
|
|
|
|
|
|
Putting DB objects in source control