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:
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:
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.