Recommended setup for Red-Gate SQL Source Control

I have my databases in TFS using Red-Gates SQL Source Control – but I’m not convinced I’m using it in the best way.

My setup is that we have one “nearly” core database that gets replicated for each client. This core is probably 90% of the objects. There is then the 10% that are client specific. For example there may be a View that filters on different names for different clients, there is a user that is unique for each client database (but linked to a standard role).

At the moment I have each client database linked to the same TFS project (in dedicated model). If there is a bug found I fix it in one client database and check-in. Then I get latest for all of the other client databases. I have to be careful when getting latest not to get objects that are different for each client (there is a generic version of each object in TFS which I use initially, but once I’ve configured the database for the client I don’t want to overwrite the database version with the one from TFS). I also have to be careful when committing changes as I don’t want to overwrite the generic version with the client specific version.

I’m sure this kind of setup isn’t unique – how are other people handling this? Any advice is much appreciated. (I’ve posted this question on http://www.red-gate.com/messageboard/viewforum.php?f=153 as well)

more ▼

asked May 13, 2013 at 03:00 PM in Default

avatar image

2.2k 3 8 15

(comments are locked)
10|1200 characters needed characters left

1 answer: sort voted first

I think this is a situation where I might use branching functionality in your source control system.

If I am reading your question correctly, you currently have a main code base, which is customised for each client (effectively, a different release, but one that is strongly related to the main code). You only commit changes that are generic - so currently, not all your code is in source control.

I would look at having your main line of code as your generic objects, with a branch for each separate client. Then you set up each client database (or rather, it's connection via Red Gate Source Control) to "get latest" / "commit" to that client's branch. This means that your code for your clients is all checked in, and you can use the source control system's (in your case, TFS's) mechanisms to handle sharing those changes between the branches and the generic branch.

Essentially, your workflow would be:

  • If I want to make a generic change, I make it on the main line and then update each branch from the main (this step could probably be automated), dealing with any merge issues. I then get latest on each client.

  • If I want to make a specific change for one client, I ("get latest" and) make it on the specific client database (linked to the specific client branch, dedicated model) and check the change in.

(Ideally, I'd have some automated process test your commits on both the client-specific branches and the main development line.)

Now, depending on how similar your client set-ups are there may be some duplication here (but no more than you currently have), however it seems to me that this gains you the advantage that your code is all checked in, there are no client specific changes you haven't got a copy of.

I would suggest a read of this branching guide specific to TFS to evaluate how this might fit what you need to accomplish.

more ▼

answered May 13, 2013 at 07:43 PM

avatar image

Dave_Green ♦
5.5k 4 5 10

many thanks for the detailed reply.

May 16, 2013 at 07:11 AM mjharper
(comments are locked)
10|1200 characters needed characters left
Your answer
toggle preview:

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

SQL Server Central

Need long-form SQL discussion? SQLserverCentral.com is the place.



asked: May 13, 2013 at 03:00 PM

Seen: 2037 times

Last Updated: May 16, 2013 at 07:11 AM

Copyright 2018 Redgate Software. Privacy Policy