Check out the new user voice for the TFS connector for Microsoft Dynamics NAV.
I am working with Team Foundation Server for our NAV team since 2010. As you can read on this blog we are using version control, agile planning and collaboration, build automation and test management. The first version of our source control plugin was based on visual studio 2010. Now we have visual studio / team foundation server (online) 2013. Time to migrate to the latest and greatest version of both products.
Our source control plugin for vs2010 was a plugin inside visual studio. That was certainly a nice solution but not perfect: one had to switch to visual studio to check-out objects and the plugin was dependent on the vs version. In order to improve the user experience we have shifted to a new architecture: we now have a Dynamics Nav connector for Team Foundation Server which runs silently in the background and does all the heavy lifting for you. You can now use the standard Microsoft Dynamics NAV development experience to develop your NAV solution and you can use the full power of TFS. This makes it possible to use the advanced features like shelving, developer isolation, build automation, unit testing and many other great features.
The connector has an easy to use cloud deployment which ensures you are always on the latest version. In the past months I have been working together with a number of alpha testers which gave great feedback. The connector is now stable and I am looking for beta testers.
Please let me know if you are interested.
Nice posters showing the agile principles!
Last week we did some improvements in our Build Automation for Dynamics NAV. One of the most important changes was on the area of Test Automation. We have integrated Test Automation with our NAV Build Automation since a year. Our initial setup was using a Microsoft Dynamics NAV Soap web service to run the unit tests. Soap web services have some limitations which makes them less suitable for unit testing. One of the disadvantages of using the soap web services is that UI elements are not allowed.
The Microsoft Dynamics NAV 2013 Role Tailored Client has been provided with command line parameters which makes it possible to run the client in console mode without a user interface. We decided to change the Dynamics NAV Build template and use the command line option rather than the soap web service. This gives us the possibility to run all our unit tests automated for each build.
Imagine the quality improvement this brought to our team. It gives insight in the tests applied on a particular build. Unit test failures are captured in the build result. As a result you have real evidence of the quality of your product in an early stage of the development cycle.
I would like to write a number of posts about this great feature and show you how you can really improve the quality of your development team.
Check out our Product Video!
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.