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.
Glad that this has your interest, and no, your "issue" hasn't been touched yet. With my posts I am detailing the general concept I did put on stage in Antwerp at the NAV TechDays, and yours will somehow be part of this. So stay tuned and, of course, keep questioning.
I'm following your posts with high interest, because to be honest there are not many sources about using Source Control with NAV. I wanted to especially thank you for this post here, because your pictures and descriptions finally helped me explaining the whole concept to my collegues :)
What I'm currently missing are some parameters in the real world. Maybe I missed a post, but somehow I can't wrap the whole concept with a real Dynamics NAV development example. Could you explain how you work from day to day with Dynamics NAV and TFS? I mean which programs you use, where your databases lie and what steps you're exactly taking to commit a change.
I guess most NAV developers have some customers with maybe some large databases. Lets say you have a customer with a 400GB database and 5 developers. Currently most NSCs seem to have one development database in their company network (lets call it Cust_DEV) in which database all the employees are developing. I've seen concepts like locking the object with a prefix in the version string (before NAV had the lock feature). Then the development begins and then the dev is unlocking the object again. Now you're releasing the object into the Cust_TEST database where your QA will take a look at it. After that you're releasing it with an upload of the .fob file to the customer system. So well thats what I'm currently used to.
Now how do I integrate TFS within this concept? I'm wondering how this works, because well you have the code in the DEV database, but now you kind of have to put this code into your source control system. Do you export every object as .txt file to even allow the merging stuff? Do you give every developer their own development database (so 400GB per dev, and thats just for one system)? If not, how do you avoid having problems with two developers working on the same object?
I hope this questions are not somewhere already explained - as you can see I'm a bit confused how to use all the knowledge I could gain through your posts in the daily life.