I picked up a new challenge these days: for one of our (quite big) customers, we need to develop a solution, based on extensions. In short: ready for the future, easy to upgrade. When I would explain the case in a paragraph, you’d say “this is not NAV”, although when you would really look deep into it, it’s ideal for an Extension-scenario, obviously in combination with Business Central.
After our exploratory talk a couple of weeks ago, I was booked for yesterday by a Dutch NAV partner to help them out on their first steps ‘into’ TFS. Using Visual Studio Online we did setup a collection and a team project , drafted and implemented a branch structure and discussed the use of work items in relation to code check-ins and scrum methodology.
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.
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.