| Author |
 Topic  |
|
|
bbakkebo
2 Posts |
 Posted - 12/05/2007 : 08:27:33
|
Hello, I have evaluated most of the products on the market now as well as my company are using db scripting and comparison products already.
I have taken a look at your process and product and while I think your product is nice, I do not understand how it provides me any more than what I do today. I would like you to point out to me where dbghost does more than what I do now. I will point out to you below why I am here in the first place.
This is my companies process today.
1.Build the db script every night through our build server. So we always have the db scripted and versioned in Subversion.
2.Use a diff against our previous versioned database to get the differences in a script, nice and neat everynight with Cruise Control.
3.So now we have difference against our previous version. Now if there is major changes, then the diff fails and we now about it, but we have to manually look at it.--problem is here
4.Causes of those manually changes are mainly renaming of things or dropping of things, etc. So this is all manual process here, we have a process to handle changes, but it is all manual here: we have to write alter statements etc and include additional sql scripts to run, basically from what I see we have to do the same with dbghost. So this is where I would love to see something better.
Now I have pointed out my problem, I have reviewed your product as well as many others and none do what we want because it appears not to exist,which doesnt mean it couldnt bed created. Well, maybe there are a few solutions out there like team system, but the cost is out of my company's range.
We want to do what we are doing above, having database updates be checked upon a build update, scripting the differences
and if there are difference conflicts be able to have a tool that resolves those differencing conflicts, so if a table was renamed for example we could just set table a=b for example and the script would be generated and included back in. So if there was column name changes the same would happen.
If there were key changes this would be determined scripted, etc. What we are trying to do is take the away as much of the manual process as we can or at least make it simple for each developer. One thing that is an abosolute is the developers do not want to have to check out and check in code. What I was think is to capture changes from a plugin to ms sql server management studio, so things were automated right from inside there for each programmer. For example if you change a table name it is all scripted and stored back into the repository for you automatically. This actually would be nice.
Let me know your thoughts. Perhaps I missed something and dbghost already has the solution.
|
|
|
leachm
124 Posts |
Posted - 12/28/2007 : 06:08:28
|
Hi,
From your description of the main problem it seems that the "custom scripts" option in DB Ghost would let you at least capture the manual changes that are necessary in source control. This means that, rather than check out, manually fix and check back in the generated difference script you would create a "before" update script, check that in to source control and rerun the build to produce the correct delta script. It doesn't help with the need for manual changes to be made it is just better in terms of change management process.
Having a plug-in is a great idea as that would enable the tricky "rename" type changes to be captured and automatically written into the "before" script and it is on our feature list :)
The difficulty here is how to synchronise the check in of the changed scripts with the other code to which the overall change relates. For example, if you updated a C# class file and a stored procedure you would have to check in the sproc in MS and the class file in Visual Studio. This would break the atomicity of the change. I'm sure we can work something out for this but I'm just trying to illustrate that this may not be as simple as it first appears.
Lastly, though, if your developers have made it an "absolute" that they do not want to check out/check in code then that, in my opinion, is a big problem.
Developers need to be aware of, and follow, good change management principles - period. I regard adherence to good team working processes (as that is what good source control practice is) as much a part of a developer's job as writing code. I have had experience of "superstar" developers writing excellent code but completely destroying project morale and, ultimately, project delivery by not working as responsible team members.
I say this having spent 20 years as a developer working on projects both big and small: SQL code is no different from any other type of code when it comes to source control. You wanna change it? Check it out first.
regards,
Malcolm Leach
www.innovartis.co.uk
DB Ghost Build, Compare and Synchronize = Change Management for SQL Server |
Edited by - leachm on 12/28/2007 06:14:22 |
 |
|
|
bbakkebo
2 Posts |
Posted - 01/08/2008 : 06:15:16
|
Thanks Malcolm for your response. We had many discussions after I posted my message in December and now our developers agreed to update things manually.
We have now taken things a little further and developed a plug-in to sql server manager which does a lot of the manual steps for us. Thus, we will drive our db update process more or less semi-automated, but the code changes are still manually done by all developers, until someone comes up with a better solution we will run development this way.
It could also be ORM is the solution for the future, but for our size(5 developers) this seems to be the best option now. |
|
|
| |
Topic |
|
|
|
Can dbghost work for us?
