Version management

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.

Advertisements

Tags: , , , , , , ,

7 Responses to “Version management”

  1. Tomas Says:

    Thanks for sharing this piece of information. I’ll definitely try applying this knowledge in my work (as I’ve already was playing with Microsoft Developer Toolkit, I’ve always wandered what else can you get from it).

    By the way, great blog, and I’ve found this just recently. You should register and let the world to know about this blog on http://www.mibuso.com.

  2. Vjeko Says:

    Hi Tomas!

    Thank you a lot for your comment, these kinds of things keep this blog running, and I am glad you find this blog useful.
    I think that this blog is not yet mibuso-ready 🙂 There is still not too many posts, and I am still testing myself whether I can commit to post something at least once per week, and in the end, if the blog thrives, it will never be too late to go-live on mibuso. But thanks for good advice!

    Best regards,

    Vjeko

  3. Dave Roys Says:

    Hi Vjeko,

    I am just starting out on a new development project and am using a couple of contracted developers as well as internal developers. I am going to use this technique of NDT to control the versions to that the developers can use their own database and I will merge their changes in to the “Test” environment. This way I can ensure that all changes are compliant with development standards and are properly commented.

    Do you have any more advice to offer before we start or is this still working out for you OK?

    Cheers, Dave.

  4. Vjeko Says:

    Hi Dave,

    No, I don’t have anything to add, other than that this adds some overhead to the development, but can truly help when you need to pinpoint the differences. I hope this will work out for you, please let me know of your experiences, I’d like to hear from other people utilizing this technique, because whenever I “evangelized” this approach, people were nodding their heads in approval, then simply forgetting about it the moment they left.

    Best regards,

    Vjeko

  5. Dave Roys Says:

    Hi Vjeko, I did some work on this yesterday and for my purposes it really isn’t going to work.
    As far as I can tell the Merge features of the NDT are centred around doing an upgrade and you are required to have 3 complete systems to apply the merge: Old Base Version, Current Custom Version, New Base Version. The Merge tool will then create a New Custom Version – any conflicts that cannot be automatically resolved can be manually merged (although I didn’t see how to do this). This looks fantastic for applying service packs and possibly even upgrades.
    What I am trying to do is manually merge in code form contracted developers, I don’t want the system to just slap it in because I want to review it first. I can’t find a way of doing this in NDT. I also don’t want to have to create all of these “full export” systems in order to do my merges since it takes NDT 40 minutes to import every object.
    What I am going to do I think is this: Use the NDT to store deliveries from the developers (a good version control, history). My developers will deliver their work as a TEXT export and I will import to NDT as a new version.
    Then I will export these objects as text as seperate files and the same objects as text from the current approved release of the development system.
    I will manually merge the changes in using beyond compare or Araxis Merge and then if I am happy with the changes, import them back in to the Current Release. I will then synchronise the changes with my testing database using the Sync to NAV Client feature or NDT.
    I realise that mine is a slightly different scenario to what you wrote about. It will be good to see how it goes. Maybe I should have written a blog post of my own instead of writing a mammoth comment. Cheers, Dave.

  6. Vjeko Says:

    Hi Dave! Yes, you are right that you can’t use this for merging code, because it has very unflexible rules about these, but you can still do comparisons, and I’d dare to say that comparison in DTK is better than in Beyond Compare. Yes, Beyond Compare surely has superior text comparison capabilities, and I occasionally I get pissed off with how DTK does text comparisons, but I’v seen BC get totally confused by NAV code. There is no perfect tool. However, DTK is much better at comparing reports and forms, and DTK as a version management tool can really do wonders at that. I am a little sad now 🙂 that the only one who actually tried this trick, is unhappy with it. Can I make up for this somehow? 😉 Cheers, Vjeko.

  7. Dave Roys Says:

    Hey, I know how you can make up for this. 😉

    Use your influence as a mighty Dynamics NAV Consultant that works for Microsoft to make the NAV Developers Toolkit Open Source. That way anyone that wants to make it the tool that it should be can do it.

    I can’t see the NDT having much of a life left, so MS really have nothing to lose.

    BTW, I realise there is no way you can actually force the product team to do this. I think I’m going to suggest this on the Connect site (that no-one else seems to be able to access.)

Comments are closed.


%d bloggers like this: