My team is currently using Visual Studio Team Services for source control (TFS), building (triggered on check-in), and deploying (using VSTS Release Management).

We have four environments (Dev, QA, Int, & Prod), and any code change has to be signed off (by different parties for each environment) before being deployed to the next.

At the moment, whenever any changes are deployed to a downstream environment, everything from the upstream environment goes at once; I've successfully convinced both the team & management that this needs to change.

Of course, that means it's on me to figure out how to change it. I pitched feature branches, but since we're on TFS the team is pushing back on that as too heavyweight; I floated migration to git, which management has agreed to in principle but deferred to an undefined point in the future.

Without changing our source control from TFS, changing our build & release from VSTS, or implementing feature branches, how can we selectively promote code changes through the pipeline of environments?

Update: Based on comments, my goal is apparently vague so I'll try to clarify. I would like to, within our current infrastructure, be able to deploy an arbitrary subset of what is in a given environment to its successor.

For example, assume that there are 5 items in the QA environment that have not yet been deployed to Int, and that the testers sign off on the 2nd & 5th ones (based on check-in order) but the 1st, 3rd, & 4th have defects. How can we deploy only the two signed-off changes to Int without also deploying the three defective ones?

  • 4
    Feature branches hurt. Have you considered toggles? martinfowler.com/articles/feature-toggles.html Commented Nov 19, 2016 at 8:25
  • Can you clearly state the problem you are trying to solve? Process you described in the first three paragraphs is very standard. Provide information about branches you are using and branching strategy.
    – Vlad
    Commented Nov 19, 2016 at 12:24
  • @Vlad, we are using a single branch. I think my last paragraph states the problem clearly; is there some way it could be improved? Commented Nov 19, 2016 at 21:13
  • I would agree with @Vlad. It's not really clear what you are asking here. " whenever any changes are deployed to a downstream environment, everything from the upstream environment goes at once; I've successfully convinced both the team & management that this needs to change." So, you don't want that? But are you asking how to change your work flow or how to achieve that in TFS? Commented Nov 19, 2016 at 21:54
  • @PaulEquis, for the time being we're focusing on ops-level changes (e.g., check-ins, deployments, &c.). If there aren't any viable, less-painful options, the team might become receptive to code-level changes like toggles. Commented Nov 20, 2016 at 0:21

3 Answers 3


If you are facing such a problem in such an environment I do not recommend to pursue granularity that small.

  1. When you dropped for QA a new release with five features you made it for a reason. Business people want them to be delivered together, implementation is tightly coupled, etc. And these reasons are not affected by the fact that subset of the release features is not ready. I.e. usually there is no really strong need to deliver subset of the release.
  2. This practice encourages piling of non-finished features across the chain instead of concentration on delivery. Instead of making bottleneck visible it creates false urge to improve everything.
  3. Usually sign-off of a feature is not enough, you have to sign-off the entire application to drop to the next stage and perform setup of this stage as well. Feature-by-feautre will multiply those efforts.
  4. To mitigate occasional need to postpone particular troublesome feature inject toggles at the very start.

What you might do

  1. Try releases of various sizes to see what gives maximum throughput.
  2. Rebalance priorities from adding features to delivering features.
  3. Regarding the 'single branch' you might want to have the same chain of branches as environments. Merge from QA to INT is not allowed until QA passes all the criteria to be ready for INT and does not imply immediate merge from DEV to QA if DEV is not ready.
  • You're giving us too much credit; the five items in QA weren't necessarily dropped at the same time, and, although the business drives the priority of what we work on when, what gets into QA is just whatever is dev complete first. Commented Nov 21, 2016 at 16:33
  • Also, the business has explicitly asked for the ability to push individual items from Int to Prod depending on the acceptance status of each; the individual items are usually independent of each other and our current process impedes getting new functionality into the hands of the customer as fast as possible. Commented Nov 21, 2016 at 16:36

You have not explained how much branches you have currently in TFS. I am not sure of current process which you follow for the feature release. Pardon me I am repeating the same below.

What I think you can do is, have four branches DEV, QA, INT and PROD. QA branch should be the last line of quality assurance of dev completed work.

One feature can have multiple checkins for development in DEV branch but the should merge all together and create one changeset when merged to QA branch. There can be some more changes from DEV to QA for the same feature if bugs are fixed or changes are requested. In short QA branch should have code dev completed and tested and ready for release.

When featured is to be released all the changesets of that feature from QA branch should be merged as a single changset to INT branch. Upon validated successfully on INT environment it should be merged to PROD branch and deploy to PROD environment from there. I am assuming here that INT environment of yours is where once the feature is deployed it stays there for a while to check the stability of it before it goes to prod.

Selective merge from branch to branch is the main idea here. You need also to have separate build scripts for each environment.

Also the build scripts should be configured to take code from respective branch.

If you dont have any branches in VCS then it will be very difficult to achieve what you want and it will be more of a manual work than automated.

  • Hmmm. What you call INT branch is typically called a "master". But why do you need a PROD branch? I compile a binary artifact, I install the same binary on regression testing environment (INT) as on PROD environment. Otherwise developers always try to sneak "small" code changes.
    – kubanczyk
    Commented Apr 20, 2017 at 7:18
  • You have a valid point. But what I am talking about here is TFS not git. The reason for keeping prod branch is for emergency where you need to fix bug directly in production code but INT branch is not same as prod branch right now. You can fix the bug directly in Prod branch and take it to production and reverse merge to int and dev. Commented Apr 20, 2017 at 8:55

You can't selectively promote the code for individual features unless you keep that code on separate branches.

I agree that feature branches are best avoided. If you test code on separate feature branches you won't know that the code performs correctly when merged together, and refactoring becomes very difficult when multiple branches coexist because the refactored code in one branch may not work with the non-refactored code in another branch.

You haven't said why you need to keep the code for certain features away from certain environments. Rather than keeping the code away, I would try to use configuration options to turn the features on or off as required in each environment.

I would also try to have extensive automated tests in place for any feature before it is approved. That should give some assurance that it won't get silently broken by code from features to be deployed in future.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.