Source Code Control in Dynamics NAV 2013 R2 – Part 1

 

I’ve promised for a long time that I’d get around to writing an article on how our team is leveraging distributed version control with Microsoft Dynamics NAV 2013 R2 and I’m finally getting the time to do this.

We’ve got a NAV development team of 5 individuals and commonly we work on multiple projects covering multiple areas of the system at the same time. We were a C# shop before we got into the NAV world so as a result we had become used to using distributed version control like Git and Mercurial. When we started to learn more about how NAV worked we realized that normally the only source control used by developers was the lock/modify mechanism built right into the NAV development environment. As a result, we decided that we’d figure out a way to use what we were familiar with, even if that meant having to develop some of our own custom tools along the way.

This will be a comprehensive multi-part series where I cover the reasons for us using source control with NAV development, our development model, basic usage of source control with NAV objects and setup data and finally some end-to-end examples using our custom built source control tool.

I’m going to assume you’ve got some background on source control systems. If not, stop over at HgInit and read through the excellent generic tutorial put on by Joel Spolsky for some primer.

Last but not least, the commercially available tools I’m using in the various pictures and posts below include:

  • FogBugz for case management & issue tracking
  • Kiln for source code control
  • TortoiseHg workbench for working with repositories

First, Why Even Bother?

Well, the advantages of using source control are many. First of all, it gives us the ability to track and view the history of our objects and setup data. Yep, I said setup data. Since setup data is text, we dump that out using XML Ports and add it to source control as well. This means not only do we have a history of all changes made to NAV objects but we’ve also got a history of all changes to setup information in the system.

diagram4

This can be especially valuable when doing troubleshooting for customers or when finding some anomalies with setups at a customer site and reverting them back to a known good configuration.

Making this even sweeter, our source control system is linked to our case management system and business requirements system. So we now have the source code changes that were made directly linked to the case logged for the bug or feature which in turn is linked to the business requirements for that particular feature or bug fix.

On top of being able to keep a history of things, we also are able to work on the same areas of the system at the same time more effectively. Nobody has to wait on someone else to modify an object.

What We Had To Build

Unfortunately, what we wanted to accomplish when we set out on the road to source control using NAV didn’t exist. Sure, you could manually export objects as text files using the NAV development environment but that would be incredibly tedious for any sort of large change across multiple objects.

As a result, we built a tool that intelligently interfaces between our source code control system and the NAV database to make our developers lives easier and automate many of the tedious tasks.

diagram5

This tool, called SCM monitors the NAV database for object changes. As objects are changed we use SCM to select and export changes objects from the NAV database and dump them into the appropriate local repository on our system. Also, we use this tool to pull in changes from other developers if more than one team member is working on the same project and code base.

Our Development Model

Each developer works locally. When they start a new project or initiative they create a new database (from a backup of a master build database… more on that later) and create a new branch and local repository. The developer then works on the features and commits locally. At the end of each work session, they push their changes up to the remote repository on the source control server for safe keeping.

This diagram demonstrates how things are setup for a single developer working on a single project.

diagram1

So How Does It All Work Together?

That’s a great question. I’m going to take you through our entire process in the next series of blog posts. We will start a new project and cover the repository structure and layout, make some changes to NAV objects, pull in other developers changes and merge them and last but not least push our changes up for other developers to handle.

Stay tuned and thanks for making it this far!

Leave a Reply