NAV Development with Team Foundation Server – Background

Way back late summer 2009. Almost a year ago NAV 2009 was out of our hands, NAV 2009 SP1 was at the verge of being pushed into the world and I … just one month ago the MS doors were closed behind me and I made my steps into the partner world picking up my new job at Imtech ICT Dynamics Solutions as Technical Consultant, which became more and more Product Manager.

Imtech ICT DS, a typical NAV partner having a drive for their customers doing all of their NAV development in various CSIDE databases. Except for copy/pasting databases there was no advanced way of securing the code, let alone more sophisticated tools to support efficient propagation of fixes and features from one code source to another. I reckon you can make an intelligent guess at the answer I did get to my question what kind of source control system (SCS) was being used. So that’s were my quest started which more or less came to a conclusion last Monday with my presentation “NAV Development with Team Foundation Server” at the Dutch Dynamics Community event in Arnhem. A retrospective of the whole process.

Now with this post I will lift it to the next level. Share our experiences with a much wider audience. Bringing Dynamics and Classic MS closer? Hopefully. Helping to prepare for the next steps in your profession? Exposing myself to your feedback. Revealing myself … do I dare to say it … do I … as an … expert on this matter. Offering my services as freelancer where you get stuck.

SCS @ Imtech ICT Dynamics Solutions

So why did I wanted us to move to a SCS (in question form)?

Major Needs

• How to safeguard our source in a more advanced way?
• How to keep our history and manage our releases?
• How to efficiently/effectively propagate features/fixes?
• How to have multiple developers working on the same project? 

Minor Needs

• How to track & trace code changes?
• How to manage and plan our development effort?

Prerequisites

• Tool outside of NAV that enables us to handle multiple products/projects (major!)
• Stay close to MS stack (minor)
• Enable efficient creation of deployable code objects, in both database and .fob format (minor)

Research

With these questions and prerequisites I started my investigation, bringing me to the DevDays in 2010. Talking to various experts. Having a very close look at Perforce. A real very close look as this was exactly what I was looking for in terms of SCS having flexible branch definitions (which TFS still is missing) and cool … yeah really cool graphical tools. But missing the sheer fact that it was not part of the MS stack and that TFS is maturing and indeed made a huge leap forward with Visual Studio 2010 in terms of becoming, no being, a complete Application Lifecycle Management (ALM) tool. Brian Keller, Matthew Mitrik and Gerard van der Pol (MS) did a good job in getting our nuts and bolts together for VS 2010 and giving some sneak previews into VS vNext.

And then, not in the least important: slowly but gradually tools are becoming available to bridge the gap between TFS and NAV:

• Revision (iFacto)
• TFS Plugin and Build System (To Increase)
• Object Manager (IDYN)

Hence we decided to get on with TFS as our SCS, and ALM, tool. But we had to deal with some inflexibilities of TFS and setting up a fitting branching strategy.

We’ll dive into these in some future post.

Notes

Feel free and download my DDC pdf-ed powerpoint here.