Cherry Pick Automated Release in TFS

Question

We have a CI process that we push our changes in a development branch to the dev server and the QA server for testing. Once we are satisfied the changes work and QA has passed their tests, we would like to cherry pick the changes from that brand and merge it into a master branch to push to our Staging and Release environments. Right now the release to dev and QA are automated in the Build/Release process of TFS. Is there a task and/or variable we can add that when we push to staging we can cherry pick the changes and merge into the master branch and move the master branch into the staging environment? Right now, this will have to be a manual process that is prone to human error and breaks our CI process to depend on manual intervention. We are using the current TFS system.

Thanks.

Answer 1

This merging process is very prone to errors. Looks like also from your process, it is a different codebase or package that was tested as it gets promoted from dev to qa or to staging.

I suggest you take a look at trunk based builds. If you are working on new features and does not belong to next planned release, it should be done in feature branches. Or once the trunk has been tested and pass integration, user acceptance, performance or security tests, then you can branch out from trunk and create a release candidate branch. Any changes from the release candidate branch needs to be merge to trunk. At this point, don't expect a lot of changes. The idea is to branch out as late as you can.

Trunk based builds is not new. It's been adapted by big/small companies that embrace the agile and devops practices.

Note: Developers that are working on a particular feature should create their own feature branch. Once it is stable then they can merge to trunk. Feature branch can then be deleted.

Answer 2

The short answer is that there's no way to automatically do what you're asking. If you wanted to do it, you'd have to write your own code to do so. And I'd strongly recommend against it for the following reasons:

What you're doing is the opposite of continuous integration. Cherry-picking correctly-integrated, working features from a code base and merging them to another branch would be better termed as continuous segregation.

By taking changes that have been tested in an integrated state against a dev and a QA environment and moving to a new branch and rebuilding, you're actually completely invalidating all prior testing done.

A better approach is to use feature toggles (aka feature flags) to disable features that are still in development, and ship the application in an integrated state with incomplete features disabled.