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:

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.

Anonymous
Related
Recommended