Blog

When I posted my last relevant post on this blog, I’ve got a comment from infonote (a visitor) how bad it was that Microsoft Dynamics NAV can’t use a versioning system. Well, as the matter of fact, it can.

One of the nice things in NAV is that at any given moment, the development environment is just a Shift+F12 away. When you are a single developer on your team or on a project, this keypress is your best friend. But if there are other people on your team pressing it with an agenda, then this keypress might as well be a combination made in hell.

Teamwork in development on Microsoft Dynamics NAV implementation projects has always been a challenge, and pre-“Sure Step” methodologies advised against it. The major issue was the simple fact that there were no built-in tools for team development, such as version control or check-in/check-out mechanisms. It is only so easy for John to edit the same object at the same time Pete edits it, and save his version just two seconds after Pete saved his own, rendering several hours of Pete’s work useless. Pete will then open this object again, only to see that his changes are missing, then he repeats his changes and saves his work, destroying whatever John did. This cat and mouse game can go on indefinitely, especially if code documentation habits are poor or non-existent. Pete and John aren’t going to like one another too much.

In typical development environments, such as Visual Studio, there are either out-of-the box tools which can help with team development, or can be installed over it. Probably the most known of these tools is Visual Source Safe, which really makes a difference and saves hours of work for the team. Unfortunately, there is no way you could put VSS to work with NAV, because NAV doesn’t use files to store its objects. The objects are stored in an encrypted format in the database, and are accessed through C/SIDE development environment only, without any possibility to squeeze a version management middle layer in between. This means that in C/SIDE there will be no such function as check in, check out, and whatever is saved replaces whatever was there before, without notice or warning, and without possibility to rollback to a previous version (unless you are using SQL Server and are willing to juggle for a while with transaction log backups and roll-forwards).

But this story isn’t a sad one.

Developer’s Toolkit for Microsoft Dynamics NAV is a tool which is so easy to oversee, and the fact that it is, is the sad story indeed. This application, which is not a built-in part of Microsoft Dynamics NAV, but is provided by Microsoft to help developers in building better systems, is often regarded as two things:

1. An upgrade tool, and as such is usually discarded in favor of generic tools, like Beyond Compare. But Developer’s Toolkit is much better than Beyond Compare even for code comparison, and I hope I will have a chance to elaborate on this topic soon.
2. A code search tool, which really comes useful due to the fact that in C/SIDE you really can’t search across objects, and as such, this tool is priceless.

So, if you don’t already have it installed, go get it (PartnerSource access required). This tool addresses a series of issues with C/SIDE development environment, one of which is version management.

But the story doesn’t end with these two. You can teach this dog quite a few new tricks. So, how do you do version management with Developer’s Toolkit?

First of all, to be able to successfully deploy Developer’s Toolkit, you need to use a database server as source. Either native or SQL Server database will do. For a long while it wasn’t possible to use SQL, but since version 2.0 you don’t need to deploy the Native database server, so there are ever less reasons not to deploy this tool in a shared team environment. Using a database server, preferably SQL, as opposed to a local native database file, gives one significant advantage: a possibility to be accessed by more than one person at a time.

There is a feature in Developer’s Toolkit, which if hasn’t yet, will definitely make you think now. It is called versions. When I first saw this feature, my first thought was: “Can this gizmo do version management?” A senior guy on my team at the time said: “No.”

What I have learned along the way, is that neither “No” or “Yes” are correct answer in any circumstance. The correct answer is always: “Well, it depends.”

So what does this versions feature really do? It is intended primarily to help you out with your upgrades. You import the base version, then modified base version, then new base version, then the toolkit creates the modified new base version. Cool stuff, and useful, too. Saves hours of work. But what else can you do with it?

What I have done on many of my projects is the following: whenever I changed anything in C/SIDE, and this change was final (such as completion of a feature development), I went to Developer’s Toolkit, then I created a new version, gave it a description which explained what kind of change was done, then I imported the objects modified in scope of that change.

What did I accomplish with this? Well, for starters, I had previous version of objects modified during my change, and I now had new version of the same objects, so I could use them to compare the differences. So, let’s say that I had a project with ten different changes, all of these changes having something to do with table 27 Item. After each of these changes, I would import the table 27 Item into a new version in Developer’s Toolkit, so in the end I had ten different versions of it.

If my customer called and explained that until change no. 7 everything worked well, but when change no. 7 was introduced, the system started exhibiting curious behavior, I would know that there was something I did with version no. 7 that stank. So I could go to Developer’s Toolkit and compare version 6 with version 7, and quickly find out what kind of changes have I introduced that made my customer unhappy. This is something you can’t do if you just develop in C/SIDE, unless you really grow into some kind of documenting changes habit, such as one I wrote about in Code of coding 2.

However, being able to quickly see what kind of changes exist between two separate versions is not the only useful feature, there is another one, which helps you save a lot of work. It is called client updating. Let’s say that in example above, we really found out something ugly in our version 7, so we decided we would rollback to version 6. However, after version 7, we had two more versions (8, 9 and 10), which can theoretically make undoing even the best-of-kind well-documented C/AL code a mission impossible. What Developer’s Toolkit can help you do is to simply select the version 7 as active version, and then simply update modified objects back to NAV client. So, you don’t need to unprogram something that you programmed previously. Unprogramming is ugliest thing there is – you can create such a mess with zero effort. What you do, is that you simply rollback.

In this rolling back, there are several caveats: your version 8 might modify an object which wasn’t modified by version 7, so your rolling back to version 6 won’t really roll back the objects modified in version 8. In this situation you need to handle this manually, but this is something you need to do manually in any version management tool where you have many source code files, so this issue is outside the domain of Developer’s Toolkit itself, and doesn’t make this feature any less useful or interesting.

But the real beauty of Developer’s Toolkit comes after you have rolled back to some previous version, because you still have all of your later versions in Developer’s Toolkit. If you decide that version 7 in our example really stank, and it better be dropped altogether, you can now proceed to easily redo the changes from versions 8, 9 and 10. You simply go to the toolkit, and compare these three versions with version 6, which marks out the changes needed to be redone, so you don’t have to really do reprogram anything. Reprogramming is the second ugliest thing after unprogramming – because when you reprogram, you don’t think much because you’ve already thought about the same thing, so you just type, and in the process you might involuntarily introduce petty errors which can later cause disasters. So, with this, Developer’s Toolkit already helps you with two of the ugliest things that can happen to you when you deal with development in C/SIDE.

Last, but not least, just imagine how useful this tool can be when you do team development? If all of your team members import their changes on regular basis into the team Developer’s Toolkit database, you end up with the repository of all previous versions which makes your life much easier if there are certain modifications which need to be excluded.

Now, I know that this kind of manual version management is hardly even close to what full-blown automatic version management systems do, this is something that can really help, especially when doing team development, and even if it introduces extra pain while developing, it will only take a short time to bring it from nuisance to habit, and when you do, you will see that your effort was worth it. For me, it did wonders.