Implementing Team Foundation Server in your Microsoft Dynamics NAV environment often starts with version control. Since NAV does not have a native integration with TFS it gives some challenges. The most important one is: what is the best structure for my source code in Team Foundation Server? The Branching Guide of the ALM Rangers is a starting point for the proper strategy.
In Team Foundation Server, your source files are stored in a folder structure. This folder structure is created at the server. While working with the source files, however, a local version is used. The structure is important since this will be used throughout the development process. What is a good practice for such a structure?
I would like to share the branch strategy we implemented in our NAV development teams. In our development team we only develop standard solutions comprising both NAV and .Net technology. There are two formal release moments per year which we have to support. We are following the scrum methodology with an iteration interval of two weeks. New features are often developed in parallel. This is our branching strategy:
In Team Foundation Server this results in the following source control structure:
- The name of the Microsoft Dynamics NAV Product / Solution (which incorporate both NAV and .Net).
- Microsoft Dynamics NAV Release; we base our solutions on a particular Microsoft Dynamics NAV release.
- The localization of the Microsoft Dynamics NAV code.
- All Microsoft Dynamics NAV Objects are stored in the Objects and Unit Tests folder.
- Each release (1201 in this example) is branched from the main branch. This allows us to merge bug fixes into the different release branches and keep track of them.
In the past two years I’ve seen different branching strategies applied on NAV development. One thing became clear: keep it simple! There are costs related to each branch level since each level has to be maintained. Costs in the sense of complexity and time. Check out the Branching and Merging Primer for a number of branching Anti-Patterns that should be avoided at all costs.
Some best practices:
- Only include necessarily objects in your source control folder. It is, for example, not a good practice to include all NAV objects in your source control folder. Large projects have a negative impact on the performance.
- Be conscious in checking in completed changes only. This gives you traceability throughout your branches. Never check in code which is not completed or which does not compile.
- Pay special attention to the localization aspects of your solution since this is increasing the complexity significantly.
- Define clear responsibilities and ownership for the different branches.