Options
Using SQL Source Control to Version multiple environments
Barry H
Posts: 10
Hi All,
I wonder if anyone can help, I work within a small team of developers and we are just looking at implementing the SQL Source Control tool and have hit a couple of stumbling blocks.
What we are trying to do is version both of our environments; Live, PreLive which span circa 14 servers and 100+ databases. We started to add a couple of servers which was fine, the problem came when one of the other developers tried to view the DBs that had been checked in.
The only way we can see to do this is for each developer to create a link to each of the DB's (which could take a while). Is there anyway to automate this or is there another solution? Can developers share the LinkedDatabases.xml file or can this be deployed to a central location and you redirect SSC to that file?
We would then link a sandbox instance to SSC to grab a copy of live and then use SQL Compare Pro to release to PreLive for UAT and then SC Pro again between PreLive and Live for the final release on the source control versions and then SC Pro between the Live source controlled version and the Live DB. Is this the correct way to achieve this? Is there a best practice to follow?
Is anyone else source controlling all environments in this way (or any other) ??
Barry
I wonder if anyone can help, I work within a small team of developers and we are just looking at implementing the SQL Source Control tool and have hit a couple of stumbling blocks.
What we are trying to do is version both of our environments; Live, PreLive which span circa 14 servers and 100+ databases. We started to add a couple of servers which was fine, the problem came when one of the other developers tried to view the DBs that had been checked in.
The only way we can see to do this is for each developer to create a link to each of the DB's (which could take a while). Is there anyway to automate this or is there another solution? Can developers share the LinkedDatabases.xml file or can this be deployed to a central location and you redirect SSC to that file?
We would then link a sandbox instance to SSC to grab a copy of live and then use SQL Compare Pro to release to PreLive for UAT and then SC Pro again between PreLive and Live for the final release on the source control versions and then SC Pro between the Live source controlled version and the Live DB. Is this the correct way to achieve this? Is there a best practice to follow?
Is anyone else source controlling all environments in this way (or any other) ??
Barry
Comments
As far as I can tell, the dedicated source control model should suit you. Far as I know all you have to do to get the latest database to your developer's local SQL Server is to create a new database, link it to source control, and get latest.
If this causes any problems, please let me know.