How can I branch my code in a way that makes testing possible without contaminating the baseline?

Question

Using TFS, we have the following:

• A main baseline
• A development branch for each development effort. These get merged back to the baseline.
• A release branch that is created with each release. Bug fixes are made here, released, and merged back to the baseline.
• Using shelvesets, we can share code across development branches if needed without contaminating the baseline. Useful for code reviews.
• When we deliver our development changes to baseline we have an automated build that kicks off and automatically places our changes on the test server.

The problem is that the business analysts can't see our changes until they're on the test server, and currently the only way to get our changes on the test server is to check them into baseline. So if the BA's find something wrong, the code is, unfortunately, already in baseline and we would have to go through the trouble of taking it back out.

Is there a way we can change our branching strategy or process to get the BA's what they want to see without contaminating our baseline?

Answer 1

Your branching strategy sounds exactly what we decided on at my company. I don't think the issue is with your branching strategy, I think the issue is that you have to check changes into the baseline in order to apply them to the test server.

At my company, changes aren't checked into the baseline until they are promoted and running in production. Release branches are what are deployed to the test servers... if bugs are found, or the BAs want to change something, we don't have to go through the pain of removing the changes from the baseline.

However, if you have a lot of concurrent releases, this can become a pain to merge all of the releases together before moving them to production, since you aren't merging into the baseline until later in the process. At my company, we have a very strict release schedule, and try to only have a single release working its way to production at a time. Because of this, waiting to merge the release into the baseline until the release has been promoted into production hasn't created any issues for us, or extra work so far...

How often do you do releases? Would you be able to deploy release branches onto your test servers, and have the baseline represent what is currently deployed in production?

(I'd make this a comment, but I'm still working on earning that privilege...)

Answer 2

I would not prefer this approach, I would suggest:

A main baseline which contains stabilized code. The code will be merged into this branch from respective release branch only after successful release.

A Release branch which gets created from Main for each release. This branch will be used to generate Release Builds and will be deployed to test environment.

A Development Branch created from Release Branch, it will be used for Development efforts and will be merged to Release when I'm ready to give my build to test.