We have the following: 1.Common shared code between products 2. Only two available test environments Overnight Integration (OI) (top of tree builds automatically deployed here nightly), and QA where labeled builds are deployed manually. It is cost prohibitive
to have more test environments due to the number of machines required in each environment. Often what happens is many changes will need to be put into the common code and allowed to burn in for weeks in the OI environment. Imagine: changes 1,2,3 and 4 (c1-4
are burning in the overnight builds). The problem is at some point in time one or more of the changes will be considered good (but not all of the changes put into the top of the tree). One of the application using the common code decides they want changes
C1 and C3 but not C2 and C4 as they have not been burned in enough and they need the changes C1 and C3 now. So the application team wants the previous version of Common with just the C1 and C3 changes added to it. How can we set up a structure of branches
to allow this and which branch would be testing the overnight integration and which for QA? Thoughts/ideas on how to have a process that can handle something like this with our test environment limitations? Thanks. (This is "somewhat" similar to
some other posts but the nuance here is different. The question is how can we structure the common or other code to allow for the burn in time of certain changes in our test environments and allow to assemble some of those changes that basically have burned
in enough to promote to one of the application teams so they can then build and QA/Label with that. Clearcase offers options of promoting activities and creating labels of promoted activities. What's the best method to handle this for TFS? Also is there a
different workflow that can accomplish the same things here?).