Merge a Branch deployed to Prod, excluding merged revisions?
nbrown@sygnia.co.za
Posts: 4
I have a question about managing patch release branches, and merging. We use SQL Source Control with SVN in combination with SQL Compare and SQL Data Compare to manage our database SDLC.
We do Production patches (which may include db schema changes) on a branch, test and deploy to Production. Assume that release contains schema change set Y.
Assume that since our last QA build (rev.1000) schema change X has been committed on Trunk. We then merge the patch code and db repository changes Y into Trunk using SVN merge. We bring our working trunk databases (Dev and QA) up to date by running the SQL delta scripts used to update Production.
This way, no Pending Commits are picked up on Trunk, and the merge is successful. So far so good, everything is working well!
Now let's say another schema change Z is committed to Trunk after this (say we're now on rev. 1037). Now we want to deploy a new QA build.
We want change X and Z to be included in the next delta, but Y should be excluded because (1) it's already been released to Prod and we don't want to run it at release (will cause errors) and (2) we already updated QA with the patch delta so it has the change that is currently in Production already, which is correct. The sequence (X, Z) should be run deploying to QA, and finally Production, and that should result in the correct final state.
When we generate delta scripts using SQL Compare, we will compare Head (rev. 1037) to the last release (rev. 1000). This will obviously pick up the merged changes too (change Y). Not ideal. There is no easy way to tell which changes are 'merged' changes.
Is there any way to tell SQL Compare to 'Exclude merged revisions' so that we get a clean delta that doesn't include patches already released to Production? Or is there a slightly different process we should be using?
The only workaround I have for this is to generate 'interim' delta scripts just before each merge from a branch, which look back to the latest QA build revision, or the last merge revision. When we deploy to QA next, we simply run the interim deltas, plus the last delta, and this will exclude merged changes - essentially skipping over them.
That's a messy workaround, and I'd like to use something a bit more robust and less prone to human error. Does anyone have any ideas?
We do Production patches (which may include db schema changes) on a branch, test and deploy to Production. Assume that release contains schema change set Y.
Assume that since our last QA build (rev.1000) schema change X has been committed on Trunk. We then merge the patch code and db repository changes Y into Trunk using SVN merge. We bring our working trunk databases (Dev and QA) up to date by running the SQL delta scripts used to update Production.
This way, no Pending Commits are picked up on Trunk, and the merge is successful. So far so good, everything is working well!
Now let's say another schema change Z is committed to Trunk after this (say we're now on rev. 1037). Now we want to deploy a new QA build.
We want change X and Z to be included in the next delta, but Y should be excluded because (1) it's already been released to Prod and we don't want to run it at release (will cause errors) and (2) we already updated QA with the patch delta so it has the change that is currently in Production already, which is correct. The sequence (X, Z) should be run deploying to QA, and finally Production, and that should result in the correct final state.
When we generate delta scripts using SQL Compare, we will compare Head (rev. 1037) to the last release (rev. 1000). This will obviously pick up the merged changes too (change Y). Not ideal. There is no easy way to tell which changes are 'merged' changes.
Is there any way to tell SQL Compare to 'Exclude merged revisions' so that we get a clean delta that doesn't include patches already released to Production? Or is there a slightly different process we should be using?
The only workaround I have for this is to generate 'interim' delta scripts just before each merge from a branch, which look back to the latest QA build revision, or the last merge revision. When we deploy to QA next, we simply run the interim deltas, plus the last delta, and this will exclude merged changes - essentially skipping over them.
That's a messy workaround, and I'd like to use something a bit more robust and less prone to human error. Does anyone have any ideas?
Comments
I'm not sure if I've understood or not, so please feel free to correct me if I've made a mistake. Are you wanting to include changes that have been committed directly to trunk but exclude any changes that have been merged in from another branch?
If that's what you want then unfortunately you won't be able to do it with our tools. Could you possibly utilise an additional branch for merging your changes? That might have a similar effect.
Redgate Software