Van Vugt's dynamiXs

All around NAV dev and test

NAV ALM with Team Foundation Server | Merge Strategy

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 ...

  1. ... 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 ...
     
  2. ... 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 ...
     
  3. ... with a forward integration (FI) from Main to Test - forward as Test is branched from Main

    and at ..
     
  4. ... with a forward integration (FI) from Test to DevelopmentDevelopment 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 ...

  1. ... to bring your Development branch in sync with Test by means of a forward integration (FI) and then continue at ...
  2. ... 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 ...
     
  3. ... 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
     
  4. ... 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 ...
     
  5. ... bring Test branch in sync with Main by means of a forward integration (FI) and then continue at ...
  6. ... 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

References

  • Hello Luc,

    I'm following your posts with high interest, because to be honest there are not many sources about using Source Control with NAV. I wanted to especially thank you for this post here, because your pictures and descriptions finally helped me explaining the whole concept to my collegues :)

    What I'm currently missing are some parameters in the real world. Maybe I missed a post, but somehow I can't wrap the whole concept with a real Dynamics NAV development example. Could you explain how you work from day to day with Dynamics NAV and TFS? I mean which programs you use, where your databases lie and what steps you're exactly taking to commit a change.

    I guess most NAV developers have some customers with maybe some large databases. Lets say you have a customer with a 400GB database and 5 developers. Currently most NSCs seem to have one development database in their company network (lets call it Cust_DEV) in which database all the employees are developing. I've seen concepts like locking the object with a prefix in the version string (before NAV had the lock feature). Then the development begins and then the dev is unlocking the object again. Now you're releasing the object into the Cust_TEST database where your QA will take a look at it. After that you're releasing it with an upload of the .fob file to the customer system. So well thats what I'm currently used to.

    Now how do I integrate TFS within this concept? I'm wondering how this works, because well you have the code in the DEV database, but now you kind of have to put this code into your source control system. Do you export every object as .txt file to even allow the merging stuff? Do you give every developer their own development database (so 400GB per dev, and thats just for one system)? If not, how do you avoid having problems with two developers working on the same object?

    I hope this questions are not somewhere already explained - as you can see I'm a bit confused how to use all the knowledge I could gain through your posts in the daily life.

    Greetings

    -Thomas

  • 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