Who, When, What and Why: Version Control for Microsoft Dynamics NAV


Have you ever been involved in a customer upgrade project in which you had to migrate a customized version to the latest Microsoft Dynamics NAV release? If so, I am pretty sure there were some mysterious changes and nobody remembered why they were implemented or if there are dependencies. If you are lucky there are some comments in the Documentation Trigger but not much more than that. It would be much easier to handle scenarios like these if a clear history was available for each individual object and for groups of objects.

Unfortunately this functionality is not provided out of the box. So how are we supposed to keep track of all our object changes? Remember: there are thousands of objects in our database and there is only one version.

For each object it is important to know who, when, what and why a change was made.

Microsoft Dynamics NAV provides us the following capabilities:

  • Object Properties; update the Date / Time and Modified properties after changing items.
  • Version List; update the version list after each object change; this gives you at least an indication something has been changed. This property, however, does not say anything about what has been changed and who applied the change and, even more important why it was changed.
  • Documentation Trigger; you can use this trigger for giving a short description why the object was changed which is a good practice for customizations or hotfixes. Most companies have guidelines about how to use comment lines. In most cases you use an id in the documentation trigger and the code is marked with the same id. This trigger, however, might give you information about why, how and when bot only for one object. It does not show you dependencies on other objects.

In our company we have different solutions, based on different versions of Microsoft Dynamics NAV. Most of these solutions are localized. In our company we are still using the options mentioned above. The only reason why we are still using them is to serve our partners and customers. For them it is still important to have correct object version information since there is a high probability they need to merge our modified objects with their version. Internally these properties are not important. We use the version list only for filter reasons. We use Microsoft Team Foundation Server to keep track to maintain the history of our solutions. 

Let’s take a real life example: One of our modules had to be enhanced with Comment Lines. To achieve this, a new table was added and some existing items were modified. After completion the Version List, Date / Time and Modified  are  updated and objects are checked in.

So what if we want to know the details about this particular change? The history is available for each individual item or for a complete folder. In this example we will check the history of our Microsoft Dynamics NAV modules. History can be activated with the source control context menu of the Team Explorer:

The history of the folder for our Microsoft Dynamics NAV Module shows a Changeset for this feature. The Changeset Details includes all objects which were changed for this specific feature:

image

It is possible to compare each item of this Changeset with the previous version as it present at the server.

And show the differences in a compare tool:

image

Conclusion: Team Foundation Server answers the who, when, what and why questions and it makes good sense to use this system for maintaining Microsoft Dynamics NAV history.

Advertisements

5 thoughts on “Who, When, What and Why: Version Control for Microsoft Dynamics NAV

    1. ronvdw Post author

      Hi Jon,

      I will post an article about the full concept we use. Version Control is an essential element of this concept. We provided team foundation with a Microsoft Dynamics NAV plugin, based on Microsoft Visual Studio extensions. This allows us to use all standard TFS source control operations for NAV. You may expect more details about this in the future. Just let me know if you want more details.

      Regards,
      Ron

      Reply
      1. Jason

        Hi Ron,

        Any idea when you may post the details on this? We are currently working with a partner that uses a customized NAV source control tool (a glorified locking mechanism). However, this tool is not a real source control tool that tracks changesets in the real sense (who/what/why). We also have the issue of multiple people working on the same objects at the same time (lots of parallel development at this point), so we can’t isolate individual features/changes easily (testing woes!). As a shop that is used to running distributed version control via Mercurial integrated with our bug/feature tracking tool (FogBugz and the Kiln plugin), we have plenty of uneasy and frustrating feelings about the current development process. We have discussed manually exporting objects, committing them locally and then pushing them up to the server as completed features, but this would require some manual work (pulling existing changes down, importing each text object one at a time, since only fob files allow multiple imports, compiling each imported object, merging changes, etc.). We don’t have a problem with this, but we are not in a position to train the partner’s developers on these processes due to time and money constraints. What would be nice is a way to automate most of this process. It’s sounds like this is similar to what you have done (the only difference would be TFS vs. Kiln/Mercurial/FogBugz). I’d be interested in the details of what you did to see if I could adapt it to our tools.

        Thanks for at least showing it is possible. I’m now inspired to spend some time looking into writing plugins for our tools now. Again, any insight into how you integrated your tools with NAV would be very valuable for our team.

        Regards,
        Jason

  1. Pingback: Who, When, What and Why: Version Control for Microsoft Dynamics NAV | Pardaan.com

  2. ssmantha

    Jason, Indeed you pointed some of the real issues what we used to face pre-TFS plugin era. Now we can manage these changes almost seamless with our integration. Not only we can find the answers to who/what/when/where but also manage automated builds with continuous integration and many more options. Kindly contact our marketing team for a demo by visiting http://www.to-increase.com/scrum.

    We would be happy to give you a demo.

    Kind Regards,
    Satya

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s