When doing software development, discussing version management is unavoidable. Microsoft Dynamics NAV is flexible in this and allows developers to make their own decisions on this subject rather than forcing them to one way of versioning.
In Microsoft Dynamics NAV, there are two ways of determining what a version is. The first and easiest approach is to change the version of an object each time it changes. The initial released Version is 1.00 and each change increments to 1.01, 1.02, and so on. A big change will lead to Version 2.00.
Another more common approach in Microsoft Dynamics NAV is to group version numbers in releases of a group of objects together. When this is applied, the application gets a version number that is incremented each time we release. This means that an object with version number 1.01 can jump to 1.04 if it was not changed in releases 1.02 and 1.03.
There are rules in Microsoft Dynamics NAV for version numbering, although the rules have changed over the years.
The current version principle allows us to use letters and digits. The letters indicate the product and country code, the digits the version, subversion, and service pack number.
Let's look at an example object to clarify this. Codeunit Whse.-Printed (5779):
|
NAV |
W1 |
3. |
70. |
01 |
|---|---|---|---|---|
|
The last service pack this object was changed | ||||
|
The last subversion this object was changed | ||||
|
The last version this object was changed | ||||
|
The Localization Version | ||||
|
The Product Name | ||||
If Microsoft change this object in Service pack 1 for 2013, the new version number would be NAVW17.00.01.
Versioning in Microsoft Dynamics NAV is done manually. The version number is an editable field in the Object table (2000000001) that can be freely changed. Developing a tool to do this is easy and has been done by many partners in the channel.
The Data and Transaction model of such a solution should look something like this:
The process starts with a change request. This can be fixing a small bug or creating a new functionality. For this change request, objects need to be modified.
Each modified object is attached to the change request. We can release several change requests at the same time. All objects in the release will get the version number from the release, which can be automatically updated in the object table.
By saving the change request and release information in the database, we will also generate documentation that will help future developers to find information on why objects were changed.
Object changes can be tracked using triggers in SQL Server. All the C/Side objects are stored in the Object table (2000000001).
To connect an object change to a change request, the developer should tell the system the request they are currently working on. This will enable us to have a failsafe tracking mechanism to perform version management.
Note
To view the complete solution for tracking object changes visit http://dynamicsuser.net/blogs/stryk/archive/2009/05/18/object-auditing.aspx.
In order to look at the changes, saving a copy of a version can be very useful. Besides the obvious possibility of saving the files on a disk, we can also use an external tool. One of these tools is Microsoft Team Foundation Server. This is a part of the Visual Studio family and from Version 2013, it is available in the cloud, making it very easy to set up and use in combination with Microsoft Dynamics NAV.
Note
The video blog at https://www.youtube.com/user/SorenKlemmensen/video demonstrates how to start using Visual Studio online combined with Microsoft Dynamics NAV.