NAV ALM with Team Foundation Server | Branch Strategy

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.

Setup 1: from development to release

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.

Setup 2: development parallel to test (and release)

So how do we go about this? By setting up a separate database for Development. That’s no rocket science. [8-|]

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

• facilitates automatic creation of branches, likewise from Main to Development and Main to Releases
• remembers the relation between these branches based on which you can perform the (reverse) integration by means of standard functions

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.

Setup 3: DTAP with multiple developers

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.

Notes

• Development / Test / Main / Releases is a standard terminology
• So far this all is not NAV specific
• For those who know labeling: to a big extend you might derive the same result by labeling, but in general I’d rather create separate branches to keep overview and prevent unwanted code changes

References

• VS TFS Branching and Merging Guide v1 – Visual Studio 2010
• VS TFS Branching and Merging Guide v2.1 – Visual Studio 2012
• Use branches to isolate risk in Team Foundation Version Control
• Branch folders and files