With my branch strategy post, I have provided you with a basis to design a source control structure to store your code in TFS. However, this is just half the story when it comes to how to keep the various branches in sync to the right extend. So here comes in the merge part of the strategy, i.e. the “what about all those FI and RI arrows going up and down?” question I left hanging in the air at the end of my branch strategy post.
Note: the branch strategies discussed (and also not discussed but to be found in the the Branching and Merging Guide by the VS ALM Rangers) can also be applied to other source control systems like Perforce.
We’ll use the DTAP setup to dive into details.
Scenario 1: hotfix implementation and propagation
A hotfix is typically issued on a release. Using the DTAP setup you would be ending up updating the code in the relevant release branch, say Release 2.1. So let’s focus on this.
A bug has been reported on release 2.1 and this needs a hotfix that at …
- … will be implemented in the related branch: Release 2.1
as this bug was also proven to exist in our current product, i.e. Main, you want to integrate this fix at …
- … from Release 2.1 into Main, which is called a reverse integration (RI) as Release 2.1 was branched from Main
to bring the rest of our structure in sync with this change we also need to propagate this to the other branches starting at …
- … with a forward integration (FI) from Main to Test – forward as Test is branched from Main
and at ..
-
… with a forward integration (FI) from Test to Development – Development is branched from Test!
As there are many roads that lead to Rome, there are various ways to achieve this hotfix implementation and propagation, the above being one of them. And alternative scenario could be the following, leaving it to you to fill in the details from steps 1 to 4.
You might consider this scenario to establish a double check before propagating the fix to Main.
Scenario 2: feature development
Clearly the development of a new feature will be done in (one of) the Development branch(es). You’ve got all requirements and some kind of technical design, thus ready to take off.
But before you start make sure at …
- … to bring your Development branch in sync with Test by means of a forward integration (FI) and then continue at …
- … to do the implementation of the feature; once ready, i.e. code ready and technically tested, you would like to propagate it to Test
now before you do this, always makes sure that code in Development and Test share the same base as this will make the merging much easier, therefor at …
- … bring Development branch in sync with Test by means of a forward integration (FI) and then continue at …
Note that in our case this FI is strictly not necessary as we already did this at step 1, however, during the time you are developing the feature, and before you want to integrate it with Test, most probably other updates have been propagated to Test, thus this FI
- … to integrate your feature from Development to Test
for the sake of ease let’s assume the feature has been fully tested and approved to be brought into Main, but, likewise step 3 above, you first need to bring Test at level with Main, so at …
- … bring Test branch in sync with Main by means of a forward integration (FI) and then continue at …
- … to integrate your feature from Test to Main
In a later stage the feature will be part of the release by means of the release creation (i.e. branch) at 7.
Notes
- Reverse and forward integrations can be performed with the standard TFS merge functionality, either from the UI or cmd
- So far this all is not NAV specific
Hi Thomas,
Glad that this has your interest, and no, your "issue" hasn't been touched yet. With my posts I am detailing the general concept I did put on stage in Antwerp at the NAV TechDays, and yours will somehow be part of this. So stay tuned and, of course, keep questioning.
b rg
Luc