I would like to learn about common practices/ methodologies for managing database version control for an enterprise database.
I am not interested in off-the-shelf data manager type implementations - b/c I have been tasked to use CVS. In my particular situation, we have a production db with ongoing bug repair and ongoing side projects (big/small) that are rolled in periodically. Any words of wisdom are appreciated in advance.
Someone - Anyone - Please reply to this post. I am in great need of help on this topic and truely need to hear what some of you experts out there are doing -so- I can learn from others rather than invent my own way. -kv148
I'm a contractor so I've worked on a few sites. All I can say is that any methodologie I've seen was always home grown. I wouldn't for one minute say there isn't anything formal, but as yet I haven't seen a formal method in use. You have to imagine, there might be good tools for the database, and there might be good tools for the client side application, but I don't believe there is anything for both - and when both are usually so tightly integrated (rightly or wrongly) we have a problem.
I have myself developed (at the request of the client) schema comparison tools etc (prod vs. dev vs. test). I've also been on sites where the front end tools were tightly controlled with VCS (usually through MS Api's).
What I'm trying to say is that while tight version control might be out there, all of the sites I have been on have not used it - and therefore I'm not aware of it. Maybe this is one case where you have to roll your own?
I'm also open to anyones suggestions as to some integrated Oracle tool that proves me wrong.
You have confirmed my suspicions, but, I am still interested in what others are actually doing out there; especially, since there seems to be no literature on the topic. Let me tell you what we are considering/ experimenting with and then maybe you (or others) could give me some pros and cons to our approach.
In summary, we have 1 production real estate database (residential only) that requires on-going bug repair with incremental updates 2x's per week.
We have several major upgrades in-progress, like expanding the schema to include commercial listings and some other side projects that will require changes to the physical layer.
To allow both on-going updates to the production database as well as promote/roll-in on-going development w/o introducing bugs into the relatively stable production db we are considering the following steps:
1.) use cvs to check in on-going repair work to prod db.
2.) use cvs branching on ddl and packages to work on 'new' major releases that can not conflict with on-going repair to prod db.
3.) deploy 'branched code' to a NEW schema. A new schema would be created every-time we intend to develop another new componenet or major release. This branched code would obvious age as step 1 progressed.
4.) once, the new major release was ready we would MERGE the changes to the code-base in step 1. Depending on how old the base code got the reverse might also be needed (merge prod db with branch to update base code)
5.) use some kind of version table that would always indicate the current version.
I have two concerns about this approach: 1.) will cvs cut the cheese and 2.) is it appropriate to spawn new temporary schemas to house new development.
WHAT DO YOU THINK ??? HOW DOES THIS COMPARE W/YOUR EXPERIENCES ??? -Thanks, kv148