Tag Archives: Changesets

Developer Isolation: enabling true parallel development for NAV – 1

Let’s start with a spicy statement: Microsoft Dynamics NAV does not support concurrent development scenarios. Of course you can argue that you can achieve some sort of concurrency by using a shared database without object cache and so on. But that is not what I mean. True developer isolation is not supported. Because of that you easily end up in confusing situations in which people overwrite each others changes.

Source Control of Team Foundation Server supports concurrent check-out out-of-the-box. What exactly is developer isolation and how is it available in Team Foundation Server? Developer isolation means each developer uses a local development environment in which the development is done. Because changes are applied in a local environment it does not affect other developers, unless the changes are committed to the server. As a result multiple developers can work on the same piece of code simultaneously. Merge conflicts are resolved at check-in or when getting the latest version from the server into the local workspace.

Let’s take a look how this works. Let’s take a scenario in which we want there are two developers (Chris and Ron) working on the same solution. Chris has to implement a Document Status Check while Ron has to work on a Customer Status Check function. Both features require Codeunit 80 to be modified.

  • Chris checks out codeunit 80 in his local workspace. He implemented some changes but did not check them in.
  • Ron has to work on the same object and almost on the same piece of code. When he wants to check the object out, he noticed it was already checked out by Chris. He smiles and checks-out the object.
  • Both Ron and Chris are working on the same object now.
  • Chris is ready with his change and checks in the code. He added a nice document status check to the code.

  • Ron just implemented his piece of code and is ready to commit his changes to the server. It happens to be Ron’s changes overlap the changes Chris just made.

  • Ron checks in his code. The system notices there is a difference between Ron’s workspace and the server version.
  • Because the version difference, the check-in triggers the merge tool automatically.
  • The Pending Changes – Conflicts window is activated automatically.
  • Ron uses the Merge Changes in Merge Tool option to resolve the conflict
  • After resolving the conflict the version in Ron’s workspace is Latest
  • And Ron can commit his changes to the server without any issues.

In this scenario I used the standard tools without any NAV extension. In following posts I would like to demonstrate how this concept can be seamlessly integrated in your NAV development process by using the To-Increase Source Control Plugin for Visual Studio.

Conclusion: developer isolation provided team foundation server is a generic concept which would be extremely useful in Dynamics NAV development scenarios. Imagine the increase of performance you’ll achieve when you can use this in your NAV development team.

Change is always inevitable and Changeset makes sense.

Let me start with a question for which I created a small poll. Please select an option to vote and then read further.

If you have not voted for option “You edit single file to resolve the issue/bug.” then you might be facing the pinch for a logical grouping of changes done to fix a bug. Team Foundation Server takes it to the level of logical grouping of changes.

Any piece of functionality we build for a software requires multiple files, until and unless you throw away all the design principles and write code in a single source file. Each and every activity in software development is a change, whether you add some files, delete some or edit some. Everything said above in TFS system needs to be checked-in, so when you see the check-in window it is visible as a pending change, ready to be committed to the source server (Pending Add, Pending Delete, Pending Edit).

Changeset is a logical grouping of the changes you do in source control, it is essentially a collection, what needs to be in the collection is ultimately controlled by the developer. So it is the responsibility of the developer to select the pending changes which would be eventually committed to the source control server.


Notice the Change types “edit”,and “add” in the screenshot above. These changes can now be checked-in as a set which we typically refer to as a “Changeset”. When I said that what contains inside a change set is controlled by developer earlier in this post, I meant that you can select which objects you want to check-in controlled by the checkbox besides every element in the above dialog.

Changeset is a linkable entity, meaning you can associate them as links with work items in TFS. Why is this important? The answer is simple, you never do any change in a software without a purpose when you consider the complete ALM picture. Each work item type, defines a purpose in the software development methodology. This helps us in understanding the purpose of source code changes, as to why we did a particular change, what was the intent behind and some more artefacts (like effort spent, developer comments, to which product functional area it corresponds to, to which release etc., will we dive into these details later in some future posts when we do a deep dive with work items).