What is the correct way to store future changes in TFS? (Can't be implemented until a certain day)

Question

I work for a company that is regulated by a government entity. They specify certain specs yearly, and often make changes that require much of the code-base to be changed.

That being said, we like to make changes beforehand to avoid the stress and rush of last minute implementation.

What is the best way to store code in a bucket with all other related code so that we can also still make feature and bug fixes while waiting on the deadline?

Would creating a private branch off the main repository work? – carlosfigueira

I'm not sure. It is a team effort so does private allow them to work as well? Do we all create individual private branches or one large branch? My biggest concern is trying to merge all these changes with the latest bugfixes and features. It seems like it would be a nightmare. If private branches help this, I'll look into them.

Answer 1

This falls under the rubric of Configuration Management. You should read Brad Appleton's book Software Configuration Management Patters: Effective Teamwork, Practical Integration. I don't necessarily agree with everything, but he's got some good advice.

Other good resources for CM are CM Crossroads, also the USENET newsgroup comp.software.config-mgt.

There are a couple of way to do things:

• Develop on the trunk and branch on release (or release candidate).

  This approach has the advantage that ongoing development is already in the trunk. The only merges that have to be done is to propagate bug fixes from a release to the trunk and to other releases.

• Branch per release. Develop on the branch, and merge into the trunk on release.

  In this approach, a new branch is cut from the trunk when starting work on a release. When the work is "release-ready", it gets merged back into the trunk, so the trunk represents a timeline of releases. Advantages here are that the trunk and its history is kept pretty clean. All the false starts, etc. are kept in the branch. Disadvantages, especially if multiple releases are being worked simultaneously is that the merge back into the trunk can be painful, if two releases step on each other in the trunk — a race condition as it were.

• Branch per feature. Assemble features to compose a release.

  This is similar to the above, but more granular. Same sort of advantages/disadvantages apply.

For what it sounds like you want to do, I would create a new branch off your existing "released" codeline. Make the pending changes in the new codeline. When it's time to push it out, merge it back into the main codeline — basically a branch for your new feature.

Another approach would be to implement the new features "dark" in the current codebase, with a configuration switch to let you enable them when you so choose. This avoids the branch and lets you easily turn the feature on. This does require extra QA effort as they need to regression test everything to ensure that in "dark" mode, the system still works the way it did before the changes were made. They also, naturally, have to test the new changes whilst enabled to ensure that they work properly.

Answer 2

You should create a separate (we call it feature) branch. Make your changes and continually merge from Main to this feature branch so you don't have a huge merge problem when you're ready to merge back to Main. When you're ready to merge and implement the changes, merge from your feature branch to Main, then eventually to a release branch.