In this post I will continue speaking about projects, but now I will come back to TFS. Today’s story is about Merge & Branch structure and strategy for projects and significant changes. In one scheme it can be presented the following:
So we have four branch directions:
- Main branch – it was the first to be created in TFS. It contains code that is working on production environment.
- Development Branch – is used to handle support tasks. It contains code that is working on the test environment of the current release. When work item is tested by business and ready to be implemented into production, it is merged into Main branch.
- Features – are used for small projects (minor changes to the system that will be developed for a long period of time – several months). Feature is branched from Development branch. Every week we merge all changes from Development into all active Features to keep them actual. Each Feature requires a user acceptance test (UAT) and before it – we merge it into Development branch and UAT is conducted on the test environment of the current release. After this merge, Feature is marked as Read only.
- Releases – are used for huge projects (tremendous changes to the system that will be developed for a long period of time – from several months to a year). New Release is branched from Main. Every week we merge all changes from Main into active Release to keep it up to date with current changes. After UAT Release is merged into Main and then from Main into Development. After this merge, Release is marked as Read only.
- Features inside Releases – are not shown on the scheme, but in my practice we have created Features inside Release. This was done to let our team perform parallel development of two blocks that must be tested one after another but implemented into production simultaneously.
Also each project or significant change, that was branched, gets its Iteration Number. The principle is the following:
- Current development node has Release number 10. So new feature iteration would get 10.01<ShortFeatureName>.1. For example Invoice Implementation will have name 10.01.Inv.1. This will be the name for development of basic functionality.
- When we start first internal test iteration – all burgs/tasks/requests will have iteration number 10.01.Inv.2, etc.
- The next feature will get name 10.02<ShortFeatureName>.1.
- When Release 11 will be implemented into production, all feature names will start from 11 then.
This numeration is used for project status reports that I’ll describe in the next posts.