All around NAV dev and test
... and enable back and forth browsing.
I often find myself in the situation that I have been navigating through some C/AL code using the Go To Definition feature of which I recon each NAV developer is still very pleased with since the introduction of it in NAV 2009 R2. For sure I am still using it on a daily basis.
Now finding myself at the end of a "chain of Go To Definition actions" I would like to navigate back towards my starting point. Having navigated from one object to another this isn't to difficult as this simple means closing each object that has been opened. But when this chain occurs in one object I have no way of easily doing this.
So I am longing for a navigation history that allows me to navigate in reverse order; even select from this history an individual intermediate stage, likewise with any internet browser; or Dynamics NAV.
If you think this awesome please go to msconnect and vote for the suggestion I created there.
As you probably have noticed I have been detailing my NAV TechDays starting with branch and merge strategies. Meanwhile "TFS brother in arms" Soren Klemmensen has taken off with how-to videos. Very instructive!
Click on the image to go to Soren's blog.
Soren has already created two videos:
Reading my posts NAV ALM with Team Foundation Server | Branch Strategy and NAV ALM with Team Foundation Server | Merge Strategy you probably have been thinking: "Thanks and well done Luc, but doesn't sound like NAV specific."You're totally right! The setups I discussed there are totally product independent; and these are only three of them. You might even study the wider range of setups discussed in the Branching and Merging Guide by the Visual Studio ALM Rangers and choose (or conceive) one that fits your needs better.
Now the logical question following would be: "Aren't there any NAV specific matters to consider?"Sure there are, such as:
In this post I am going to elaborate on how you could incorporate NAV standard in case you are developing a product for a local market (bullets 1 and 2). In later posts I might pay attention to the more broader picture of the third and fourth bullets.
So your add-on is being developed for a local market in, let's say, the Netherlands (NL), meaning your code is added to NAVNL. Partly new objects and partly customized NAVNL objects.Therefor we need a container to hold the NAVNL code (NAV/main) which we branch to our add-on (add-on/main):
To this add-on branch we will apply a strategy as discussed in NAV ALM with Team Foundation Server | Branch Strategy.The schematic TFS structure would then look as follows:
Applicable hotfixes issued by MS will first be checked-in into NAV/main from where it will be integrated into the add-on:
In the different development setups I have been working so far I have implemented a number of extra layers, which more or less results in a structure as displayed below:
... to all of you.
I hope on next New Year's Eve you will all be able to look back upon 2014 concluding that it has been worthwhile, whatever it was that crossed your "road". Goosebumps on your skin, love in your heart, even though that "road" can be very, very, very tough.
Thanx to all that across my road in 2013.