MonthSeptember 2014

NAV 2015 is apptastic!

If you’re in the Dynamics NAV world, you probably already know that NAV 2015 has been released to partners (get it here), and will be available to the general public starting October 1.
One of the new features of NAV 2015 that has me very interested is the tablet interface.
This is a topic that has been kicked around a lot over the past few years with regards to the NAV products I’m involved with. At some point, there’s a line where adding more functionality just adds clutter to the end user. In an age where apps rule, users are quite adept at having a suite of apps that do fewer tasks, but more efficiently.
The tablet interface gives us a way to deal with in the ERP world. Yes I realize we could have been building apps for the past ‘x’ years, but that comes with a lot of overhead, especially if it means a NAV developer having to learn a new programming language. With the NAV 2015 tablet interface though, there’s no additional development that needs to be learned. If you can create pages, you can create tablet interfaces. For end-users, the ability to “pin” or “favorite” multiple NAV 2015 tablet URLs, means that they can essentially build their own toolbox of “apps”, based on the tasks they need to do. Of course, being cross-device compatible is pretty neat too!
I’ll cover more on this in the future as I get my hands dirtier with it, but for now let’s sit back and enjoy the fact that finally it’s easy to bridge the gap between ERP and your device.

Source control…is it really worth it?

Alright, thought I’d kick things off here with something that has become a large part of my life over the past 5 years or so; source control. More importantly…Microsoft’s Team Foundation Server.
Yes, I’m sure by now that you’ve seen a number of blogs that are out there touting the power of TFS and what it can do for you, and those blogs would all be correct. What I want to do here though is not talk “how-to” here, but rather dig into what it’s like to move to TFS, and what are some of the benefits that come along with it.
First off, I won’t lie, moving to a TFS system is not necessarily a piece of cake for everyone. For some it’s a complete shift in the way development is done, and to introduce source control to the world of NAV which has had next to no controls in place since day 1…well that can be tricky to say the least.
I was a NAV developer for about 6 years when I was introduced to TFS. Right away, I was in the “I’m not using that” camp. Why would I? I’d been making out “fine” without a source control tool, so of course adding a tool to the process would only make developing harder and the whole process longer. An administrative headache I think I once said. Well, fast-forward over 5 years later and I don’t know how we could live without TFS.
Ok, probably some time for a bit of background. I started at IndustryBuilt Software in 2003. I’d only been a NAV developer for just over a year or so at that point. I, as was common back then for most NAV developers, worked on custom projects where each project was different from the last. Skip ahead a few years and I moved to a still rather new department, the one that was doing things that few others were doing at the time; they were building vertical product! That’s when things got truly exciting!! We could finally concentrate on building out a product platform that we could roll out to a number of customers.
It was a few years into building product that TFS came along as this “cool thing we need to try”. So….reluctantly I tried it. It was weird, cumbersome, and yeah at the start it did add overhead to the way I did things, but the things it opened up for us was amazing! We were able to track our builds from week to week. We could see what was changed in the core NAV product to see what impact it had on our product. We could take our entire development process and empower each developer with their own development database and TFS workspace. No more did we have to check with other developers to ensure we didn’t change the same object as they were working on.
Fast forward to the present. The product development team (now referred to as R&D) has grown by more than 300% and has had anywhere from 4-7 developers amongst the group. Without TFS I don’t know what we’d do. We have .NET developers and NAV developers all working within one development ecosystem, all playing with the same tools. Further to that, all of our product initiatives and features are managed using TFS. We’re also a year into implementing the agile scrum process, all within TFS.
We’re able to implement the Cumulative Updates from Microsoft every month within just a few hours. We’re able to publish our own hot fix rollups each month to our implementation team. Finally, we’re able to upgrade our products without having to stop the normal course of development. All with TFS.
Oh, did I mention as well that our implementation and support teams also use TFS to manage every single customer project? That’s right, every customer that comes on board gets their own branch in TFS, where all changes (custom or not) are tracked in the same manner that we track the R&D work.
So, at the end of what has become a rather wordy post, let’s reflect on the real message here: TFS is by far an invaluable tool for any development team. From the 1-man show to the multi-developer team, everyone should get on the TFS train. Sure, it may be a bit of a culture shock, but the return is definitely worth the effort. The first time you need to roll back a change because something broke in the 11th hour of putting together a product release is when you will “thank the TFS gods” so to speak and wonder how you ever made out without TFS for all those years.

© 2020 NAV Bits and Bytes

Theme by Anders NorénUp ↑