Reading my posts NAV ALM with Team Foundation Server | Branch Strategy and NAV ALM with Team Foundation Server | Merge Strategy you probably have been thinking: "Thanks and well done Luc, but doesn't sound like NAV specific."You're totally right! The setups I discussed there are totally product independent; and these are only three of them. You might even study the wider range of setups discussed in the Branching and Merging Guide by the Visual Studio ALM Rangers and choose (or conceive) one that fits your needs better.
Now the logical question following would be: "Aren't there any NAV specific matters to consider?"Sure there are, such as:
In this post I am going to elaborate on how you could incorporate NAV standard in case you are developing a product for a local market (bullets 1 and 2). In later posts I might pay attention to the more broader picture of the third and fourth bullets.
So your add-on is being developed for a local market in, let's say, the Netherlands (NL), meaning your code is added to NAVNL. Partly new objects and partly customized NAVNL objects.Therefor we need a container to hold the NAVNL code (NAV/main) which we branch to our add-on (add-on/main):
To this add-on branch we will apply a strategy as discussed in NAV ALM with Team Foundation Server | Branch Strategy.The schematic TFS structure would then look as follows:
Applicable hotfixes issued by MS will first be checked-in into NAV/main from where it will be integrated into the add-on:
In the different development setups I have been working so far I have implemented a number of extra layers, which more or less results in a structure as displayed below: