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 most cases we use NAV standard as the basis of the product we are developing
- Potentially we are not the only one making changes to this standard code as MS is frequently releasing hotfixes that we might want or need to incorporate into our product
- Using (other) add-ons into our product in the same matter as NAV standard
- Developing a product for an international market, i.e. being released to various local countries
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.
Local Add-on
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:
Additional Layers
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:
Note that …
- NAV contains copies of the RTM code of all versions that have been relevant to us so far; this not only has historical sense, but has proven its worth dozens of times when needing to compare current code with previous versions of NAV
- NAV/main is the folder as discussed above and always contains the code of the NAV version we are currently “on” with our product
- Above NAV you might have noticed that the folder dynamics_NAV_development; this is the name of the Team Project that holds our NAV code (next to possibly other team projects holding .Net code)
- Anywhere product (or add-on) is mentioned this can also be applied to project