2

I'm trying to figure out how to implement version control in an environment where we have two DBs: one Testing and one Production.

In Testing. there are an arbitrary number of tasks being tested. These have no constraints in number of objects manipulated and complexity, meaning we can have a 3-day task that changes 2 package bodys and one trigger, and we can have a 3 month task that changes 100 different objects, including С source files and binary objects.

My main concern are the text-based objects of the DB. We need to version the Test and Production code, but any task can go from Testing to Production with no defined order whatsoever.

This means right now we have to manually track the changes in the files, selecting inside each file which lines in the code go from Testing to Production. We use a very rudimentary solution, writing in the header a sequence of comments with a file-based version number and adding in the code tags with that sequence to delimit the change.

I'm struggling to implement SVN because I wanted to create Testing as a branch of Production, having branches in Testing to limit each task, but I find that it can lead to many Testing tasks being ported to Production during merges.

This said, my questions are:

  • Is there a way to resolve this automatically?
  • Are there any database-specific version control solutions?
  • How can I "link" both environments if the code base is so different?
bahrep
  • 29,961
  • 12
  • 103
  • 150
jcd
  • 300
  • 2
  • 13

1 Answers1

0

I used SVN for source control on DB scripts.

I dont have a technological solution to your problem but i can explain the methodology we used.

We had two sets of scripts - one for incremental changes and another for the complete declaration of database objects and procedures.

During development we updated only the incremental changes in a script that that was eventually used during deployment. during test rounds we updated the script. Finally, After running the script on production we updated the second set of scripts containing the full declarations. The full scripts were used as reference and to create a db from scratch.

haki
  • 9,389
  • 15
  • 62
  • 110
  • My problem is not with deployment, the Production DB is running and we're not deploying any other instances. We just need to eliminate the hand work in merging tasks from Testing to Production. We're always developing in Testing and every week new things go to Production. – jcd Jul 26 '13 at 13:31
  • I'm not sure I understand the problem then - we also had lots of changes - we just manged changed in a change log manner. Each developer had to send all it's changes to the DBA who was in charge of integrating and maintaining the change script. If you are looking for an automatic tool to perform this task then I don't know any (if there was one we might have had more unemployed DBA's). – haki Jul 26 '13 at 13:42