asked
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)
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][1] to evaluate how this might fit what you need to accomplish. [1]:
http://vsarbranchingguide.codeplex.com/
14 People are following this question.
