Version and release control is very important when working with any large or business-critical systems, more so once they have gone live.
In such systems, there would normally be multiple developers working on different functional areas, and there would be times when immediate/hot fixes would be required to be applied to specific versions of the systems. Without proper version and release control, the developers may need to stay away from making major changes when a deployment is due, or hot fixes may include deployment of incomplete features or may not even be possible.
With TFS branching and merging, it is possible to come up with an approach to minimise interruptions and for better control of system releases.
The structure below is what I find working effectively:
There are three branches, each branch contains a full copy of the solution source code files.
- Dev (vNext)
This is the development branch. Developers can work of this branch continuously without interruptions.
Once a function has been unit-tested, the code is merged to this main branch ready to be system-tested. To system test, build the solution of this branch and deploy to the UAT/PRE-UAT environment.
- Release branches
Once system tested and is ready for a release, create a new release branch to reflect the new version number: e.g. v1, v2, v3, etc. or as how I prefer it, yyyy.MM.dd.xx, where xx is the release number for that day.
The importance of creating these release branches is so that when there are issues with specific releases, you can easily access the code and apply immediate fixes. The fixes can then later on be merged into Main and then back to vNext.