It's all about the answers!

Ask a question

Avoiding cherry picking with continuous deployment

Doug Verhun (75169) | asked Jan 22 '13, 5:33 p.m.
edited Jan 22 '13, 10:23 p.m. by Millard Ellingsworth (2.5k12431)

I'm sure there is a suitable way to deal with this, so just wanted some opinions on the best way.  We currently have a .NET project that has RTC setup with one stream per environment (Dev, QA, UAT, and Prod) using a continuous integration strategy.  Developers are always accepting the latest changes before delivering their code.  As a change is promoted from one env (and stream) to another, the entire code base is compiled into one executable and deployed .  My question is how do I handle leaving out changes that aren't approved, while still elevating changes that are? Ex):

Work item 'A' is put into UAT and approved (app_v1.exe)

Work item 'B' is put into UAT but has failed testing and is reopened (app_v2.exe)

Work item 'C' is in UAT and is approved (app_v3.exe)

How do I promote work item 'A' and 'C' while leaving out 'B' if deployments are done in a 'full code base compile' deployment (meaning app_v3.exe would have changes from work items A, B, and C)?  And how do you account for a scenario where work item 'C' made changes to the same file(s) as work item 'B's?

Accepted answer

permanent link
Tim Mok (6.6k38) | answered Jan 23 '13, 10:50 a.m.
Currently, you won't be able to deliver the 'C' change sets without the 'B' change sets if the changes build on top of the 'B' change sets. There will be a gap when you try to deliver 'C' without 'B'. - This plan item seems to be the functionality that you want.

The only way to get those changes delivered to the next stream in the pipeline is to create a new change set with just the changes from 'C'. It's not nearly as elegant because it will require merging when the 'B' changes are delivered.
Doug Verhun selected this answer as the correct answer

Your answer

Register or to post your answer.