v1 Migration scripts and branching in TFS
Tondeo
Posts: 2
I have a question about v1 Migration scripts and branching in TFS. We are using SQL Source Control v3.7.6.281 (Frequent Updates) and SQL Compare 10.7.0.18 against SQL2012 and TFS 2013.
This is a simplified representation of our repository branching structure:
- Database
- . . migrations
- . . trunk
- . . branches
- . . . . dev
- . . . . test
NB: SSC v1 migration scripts are all stored in the migrations folder. The test branch also serves as pre-production.
All development occurs against a dedicated sandbox database (one per developer) and we use SQL Source Control in SQL Server Management Studio to manage all repo commits and also when committing any migration scripts.
We then use SQL Compare to deploy each completed feature from the dev branch in TFS to the shared dev database. This works as expected and any migration scripts get correctly incorporated. Then at some point we merge selected changesets from the dev branch to the test branch in TFS.
The problem occurs when we try and use SQL Compare to deploy from the test branch to the test or production databases. The migration scripts do not get picked up resulting in having to manually edit the deployment scripts.
I know that RedGate stores the location of the source and migration scripts as extended properties on the target database (along with the repo version). I have changed the value for "SQLSourceControl Scripts Location" in our test and production databases to reference the test branch (as this is where both DB's would be released from). Given the above structure the value for "SQLSourceControl Migration Scripts Location" is the same for all databases. I have also double-checked that the case is correct for each path value (having read somewhere of an issue with case-sensitivity)
Is this an issue with our repo branch structure, a problem with SQL Compare config/Red-Gate extended property values or do I need to switch to v2 migrations?
Suggestions welcome!
Thanks in advance,
Terry
This is a simplified representation of our repository branching structure:
- Database
- . . migrations
- . . trunk
- . . branches
- . . . . dev
- . . . . test
NB: SSC v1 migration scripts are all stored in the migrations folder. The test branch also serves as pre-production.
All development occurs against a dedicated sandbox database (one per developer) and we use SQL Source Control in SQL Server Management Studio to manage all repo commits and also when committing any migration scripts.
We then use SQL Compare to deploy each completed feature from the dev branch in TFS to the shared dev database. This works as expected and any migration scripts get correctly incorporated. Then at some point we merge selected changesets from the dev branch to the test branch in TFS.
The problem occurs when we try and use SQL Compare to deploy from the test branch to the test or production databases. The migration scripts do not get picked up resulting in having to manually edit the deployment scripts.
I know that RedGate stores the location of the source and migration scripts as extended properties on the target database (along with the repo version). I have changed the value for "SQLSourceControl Scripts Location" in our test and production databases to reference the test branch (as this is where both DB's would be released from). Given the above structure the value for "SQLSourceControl Migration Scripts Location" is the same for all databases. I have also double-checked that the case is correct for each path value (having read somewhere of an issue with case-sensitivity)
Is this an issue with our repo branch structure, a problem with SQL Compare config/Red-Gate extended property values or do I need to switch to v2 migrations?
Suggestions welcome!
Thanks in advance,
Terry
Comments
Could you ensure all link URLs are 100% identical please?