When Rene Gayer informed his fellow Dynamics NAV MVPs, me included, about his new book on NAV 2013, I directly volunteered to read it and provide him with feedback. Looking back I guess I did not fully understood the implication of the first lines in his May 28, 2013, mail to us:
finally..uff our new Book NAV 2013 Inside will be available on 01.06.2013..puuhh deferral of 6 month .. hard work ..
Now finally having read this 500+ pager, I do. I guess you understand why it took me almost half a year to get to finish the book, next to doing some many others things. As said a 500+ pager, discussing zillions of useful things about NAV 2013. Both Technical and functional.
But let me, before I continue, first make a small, but essential, correction here: it's not his, i.e. Rene's, book alone, it's a joint cooperation of three Dynamics NAV pros, who did a darn good job by compiling all this information into this Inside. Thumbs up for Rene, Michaela and Christian.
Just a simple glance at the table of contents shows the extend of the book:
Being around in the NAV world for almost 15 years now, and having been included in the TAP program of NAV 2013, I had some smug internal voice wondering if it would really be worthwhile for me to read it at all; to spend my precious time on it. Luckily there were still other voices taking a so much different standpoint. Thank you!
Now having taken the trouble of reading the book, I am glad I did. Now I know that, next to the standard Microsoft Dynamics NAV 2013 resource on MSDN, I can turn to this resource and most probably find answers regarding NAV 2013 issues. Or direct others to, and herewith do!
Of course you might wonder, if I am only positive to help Rene et al, and that's not the case. I really like the book for what it is, forwhat I said above. But indeed, there are a couple of minor points:
But these will not keep me from using the book.
Did I convince you of the value of this book? Then go out to msdynamicsbooks.com and buy a copy yourself.
With my branch strategy post, I have provided you with a basis to design a source control structure to store your code in TFS. However, this is just half the story when it comes to how to keep the various branches in sync to the right extend. So here comes in the merge part of the strategy, i.e. the "what about all those FI and RI arrows going up and down?" question I left hanging in the air at the end of my branch strategy post.
Note: the branch strategies discussed (and also not discussed but to be found in the the Branching and Merging Guide by the VS ALM Rangers) can also be applied to other source control systems like Perforce.
We'll use the DTAP setup to dive into details.
A hotfix is typically issued on a release. Using the DTAP setup you would be ending up updating the code in the relevant release branch, say Release 2.1. So let's focus on this.
A bug has been reported on release 2.1 and this needs a hotfix that at ...
... with a forward integration (FI) from Test to Development - Development is branched from Test!
As there are many roads that lead to Rome, there are various ways to achieve this hotfix implementation and propagation, the above being one of them. And alternative scenario could be the following, leaving it to you to fill in the details from steps 1 to 4.
You might consider this scenario to establish a double check before propagating the fix to Main.
Clearly the development of a new feature will be done in (one of) the Development branch(es). You've got all requirements and some kind of technical design, thus ready to take off.
But before you start make sure at ...
In a later stage the feature will be part of the release by means of the release creation (i.e. branch) at 7.
So after my manifold "pledge" to go there and start today you might have been playing around with TFS. You did put your code there and started to update it with bug fixes and code enhancements. Great, but then you might have wondered: how does this all relate to the NAV production environment you're working in daily? How does this relate to the DTAP paradigm? Here is where the branch strategy comes in and which I am going to elaborate on in this post.
Let's say you have an add-on version 2.0. It's stored in a centralized database, well tested, thus stable, and as with any product, state of the art ... now. But as we all know, software contains flaws next to restricted functionality. So in the near future you will be updating the code, which will be released as v2.1.
Even without having any source control system, with Dynamics NAV, you will implicitly be ending up branching your code for release by means of a .fob file that is deployed to your customer as the objects in the .fob file contain all your code.
And the same applies for the next version, 2.2.
Translating this setup to TFS schematic, would look like:
Main holds the code you develop and test on, and Releases the code that has been put into production at your customer. A structure with the advantage of being simple, but as you might guess, some drawbacks 'cause how to handle parallel development and testing in general; or more specifically: how to handle parallel development once you approach the release date. In this simple setup you most probably have to set development on hold, apart from bug fixing, to be able to conduct the final tests.
So how do we go about this? By setting up a separate database for Development. That's no rocket science.
Now, parallel to whatever is happening in the Main database, coding can continue in Development. Once the isolated development, relevant to your release, has finished, the code can be (reverse) integrated into Main, where test will be performed to prove the code valid (or not). Of course this reverse integration will be happening various times during your next release project. For every feature being delivered to test, for fixes for bugs found during test, etc.
As said: no rocket science, and TFS will be helpful on this as it
Depending on your exact need, we could continue building even more complex structures, but we will not, apart from one case: the setup I used in my NAV TechDays presentation. For more setups please refer to the Branching and Merging Guide by the VS ALM Rangers.
Looking at the setup I used in my NAV TechDays presentation, we can clearly distinguish separate branches for Development, Test, Acceptance and Production and in addition we also have separate branches for (feature) development.
Or schematic in TFS:
You might wonder: what about all those FI and RI arrows going up and down? I will elaborate on that in a next post, on merging.
Misty, autumnal Sunday late afternoon. Lost our field hockey match. Shoot. But won - again! - a game of Stone Age. YES! So now, time to sit down and start my elaboration on my NAV TechDays presentation on NAV ALM with Team Foundation Server, while my dear wife is preparing our diner. Thanx, Sas!
I had set, as primary goal for my presentation, to convey my enthusiasm for TFS and rouse it with my audience. Given the number and character of reactions I got there after, I gladly can conclude I did reach my aim. To achieve this, however, I deliberatly left out details, that might be of importance for you, once you get started with TFS within your NAV development. In the next sequel of posts I will work out on My Top 5, being the central framework I had composed my presentation around.
Whereas the chronology of my presentation served the aforementioned goal, the chronology of my posts are meant to help you make the right decisions in setting up TFS for your NAV projects or product development. This leads us to the last entry of my top 5: 5. Branch & Merge, as we first need to make sure that we set up a valid and useful structure for our source control before we can set off with any project or product development in TFS.
But stop: let's not run to fast here as I will put each of my elaborations in individual post and will create some kind of table of contents in this post. For each individual post a link will be added here:
While me and my colleague Marcel were digging ourselves into NAV's cost calculation, Visual Studio 2013 was offically launched. Thus having missed all excitement and live communications, this morning I had a first and quick browse through all the news that was shared on this event. You might have seen some of the things I retweeted. Having been using Team Foundation Service for my NAV TechDays presentation this almost trivial thing directly caught my eye: the rename of Team Foundation Service into Visual Studio Online.
To get some more details read Brian Harry's article Visual Studio Online updates - Nov 13.
Based on the free availability of Team Foundation Service, uhhh, Visual Studio Online, I did my utmost best in my presentation to convey the message: Get there and start today. No complex installation to stop you from start using (or at least investigating th use of) TFS for NAV development. And also no cost to keep from starting. So go there and start today: http://www.visualstudio.com/.
For details on the 2-fold offering (Basic or Professional): http://www.visualstudio.com/en-us/products/visual-studio-online-Overview-vs.
So don't stop here, but get there and start today.
If you missed this "message" during my presentation I am sure you got it now ;-).