Database Change Management
Database Change Management
Home | Profile | Register | Active Topics | Active Polls | Members | Private Messages | Search | FAQ
Save Password
Forgot your Password?

 All Forums
 Managing Changes To SQL Server Code
 General SQL Change Management Discussions Forum
 DB Ghost first use
 New Topic  New Poll New Poll
 Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  


14 Posts

Posted - 04/05/2013 :  12:21:14  Show Profile Send bitshift a Private Message  Reply with Quote
I've used DBG in a previous position, and now I'm leaning heavily toward getting it at my new position because it worked so well. However, I didn't setup the build from start to finish at the old job, but now I am

I've gone over the "process" notes in the help docs, and online etc, but still have a few questions I'm not sure about. I've also scripted out my database(s) and placed the scripts into source control.

However, first I am a little unsure about establishing the environment to begin with.

I think the first thing I need to do is get a recent copy of our production DB, copied over to Dev and my local workstation.

Can someone review the following as I see it? I think my main thing I am unsure about is establishing the environment in which builds will be done. I currently have a Dev/Test server and a production server, as well as my local workstation with an instance of SQL on it.

So basically, I need to blow away the Dev database with a new backup from production, and do this locally as well...sound right?

Once the environment is established, then the overall build process becomes...
- get local copy of scripts from source control
- apply updates to script source
- run db ghost build against local instance using script source
- if no errors, commit script updates to source
- build target database using script source

Google AdSense

Mountain View


68 Posts

Posted - 04/05/2013 :  12:35:06  Show Profile  Visit dbghost's Homepage Send dbghost a Private Message  Reply with Quote
It sound as if you are well on the way. Regarding your step "- apply updates to the script source", of course you don't actually need to edit the SQL script if you don't want to, you can make the changes using the SQL Server designers in the Management Studio and script out the object again. If you set up the options in SSMS scripting correctly it will produce an object creation script compatible with DBG source script.
Go to Top of Page


68 Posts

Posted - 04/05/2013 :  12:41:08  Show Profile  Visit dbghost's Homepage Send dbghost a Private Message  Reply with Quote
Yes it is good dev practice to get latest and do a local build with your changes before checking in you'll need to test it locally anyway, in the same way that you would try "compiling" any other programing language before checking it in. Think of DBG Build as a database compiler if you like.

It depends how risk averse your development process requires you to be. For trivial changes you might just check it in and wait for the daily or official build results.
Go to Top of Page


68 Posts

Posted - 04/05/2013 :  12:54:54  Show Profile  Visit dbghost's Homepage Send dbghost a Private Message  Reply with Quote
Daily or continuous Build process
Here is a skeletal daily or automated build process that I always take as a start point...

It can be automated using DBGhost and your source control systemís command lines or the steps can be done manually.

1/ Get latest scripts or the labelled scripts representing the version you want to build from the source system.
2/ Use DBGhost to build a new database from the scripts (MyDatabaseBuiltFromScripts).
3/ Restore a baseline database as MyDatabaseWithData.
4/ Use DBGhost to compare and upgrade using MyDatabaseBuiltFromScripts as the source and MyDatabaseWithData as the target.
5/ We now have a new empty schema for this build version and a database with test data.
6/ Back up MyDatabaseBuiltFromScripts and MyDatabaseWithData to a folder with this version name for the developers or QA to use.

NB. a baseline database could be a cut down copy of our last released database with representative data or even a recent cut from live.

NB. step 2 checks that all the code still works together and identifies syntax errors, circular references etc.

NB. Step 4 not only produces a database that is useful for testing and developers but also rehearses your eventual release upgrade. Also if your data in the cutdown baseline is properly representative of your live system you should hit all issues like adding undefaulted not null columns to tables that have rows in live or removing static data that is referenced in live. It is obviously better to find these issues during development rather than at release time.
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  New Poll New Poll
 Reply to Topic
 Printer Friendly
Jump To:
Database Change Management © Copyright 2005 Innovartis Ltd. Go To Top Of Page
Snitz Forums 2000
RSS Feed 1 RSS Feed 2
Powered by ForumCo 2000-2008
TOS - AUP - URA - Privacy Policy
ForumCo Free Blogs and Galleries
Signup for a free forum or Go Banner Free