Recommended setup for Red-Gate SQL Source Control
mjharper
Posts: 26
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://ask.sqlservercentral.com as well)
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://ask.sqlservercentral.com as well)
Matt
Comments
One other option we came up with is to look at filters- you could add a filter to each customer database to effectively exclude all the customer-specific objects. You can read about filters here. This means you can safely get/commit objects and know they are just the shared ones (assuming you set it up correctly)
The downside of this of course, is setting up the filters requires some initial configuration (and possibly ongoing maintenance). Also, if there are dependencies between objects you're changing and the customer-specific ones, you may find that customer specific objects still get committed. You can turn off dependencies by editing the options
Hope that helps!
Redgate Software