I have just started using Visual Studio Team Services (team foundation server/TFS) to manage some of my NAV projects.
Love it so far, and its free up to five users. Still a lot of challenges, but mostly PowerShell seem to be able to handle it. Several of my MVP colleges have made a lot of videos on YouTube about TFS and NAV Source code management that I can recommend.
Source code control is actually just a small part of TFS. Its so much more. Like build-in bug and feature requests, testing and builds.
But one thing that is a bit annoying when you manage Navision projects on source code level, is the cascading changes that happens when you change a field name. Don’t know if cascading changes is the correct technical term. What I mean is if you change the field name, then every object in NAV, where this field is used, then the source is also changed. Despite the actual object does change physically.
So we end up with a lot more source code changes than actual changes!
Has anyone found a solution to this.
Not doing it would of course be my own first response, changing the caption instead, but sometimes that’s not really enough.
Simplest way of doing this is: export all your objects into your workspace (using PowerShell) and TFS will check-out all the objects that have changed. Ideally this should only show the objects in your “cascade”. The prerequisite is that before you started implementing this change in your NAV environment, code in NAV should have been synced with your TFS workspace (using PowerShell).
This is the work I am doing on a daily basis.
BTW: make it, that, before you checkin, you compare your pending changes with the latest version in TFS, to be sure that you checkin the right changes/objects.
Hi Luc,
Sure. But I knew you would look in here when you had the time! [;)]
Exporting all objects each time just seems like a lot time used, if just changed a few objects. But of course that’s only required if you did do a field/object name change.
I did flick together a few PowerShell scripts both to export and split the objects “automatically”.
But with all objects it still takes a lot of time, especially if you include the time to copy, check-in, merge etc. I would say basically an overhead of 30+ minutes just to handle the objects, before you have it at the customer.
If you only use the “change” mark and manually export your few changed objects, then its still a lot faster.
Do you also always “import” all objects, when update your live databases?
No, I do not always do this full export. I only export the objects I am working on. And BTW: I always do that manually, basically because we tend to cut features into small parts. Scripting this does not really make sense. Let’s say the scrum way: not more than a couple of hours or maximum of a day or 2.
When updating my database I rely on the fact that this is a task I do at least once a day, when I start working. In TFS I first merge all changes from others into my branch and then I import only those objects that have changed since the day before. We still do that manually (also) as we have not put effort in scripting that and … we do it quite fast. But of course there could be some hole in this mechanism and for that, among other reasons, I always do the compare I mentioned above.
Have you already registered for my workshop at NAV TechDays? This what we will be working on.
Well the branching is quite challenging to get right. It seems very difficult to change, once you did it wrong.
The question here is really how to get “the correct” structure in place so that both the Microsoft “base” branch and my project branches are in a relationship that allows for merging.
I think I start to understand how it works! [:D]
Will consider the workshop, will be at TechDays anyway. Do you have a link to the workshop agenda/sign-up?
