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 new Team Foundation Server Connector for Microsoft Dynamics NAV
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.
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!
In the Business Integration Solutions team we are applying Scrum and TFS to develop our next generation of Business Integration Solutions on Microsoft Dynamics NAV 2013. Check out http://blog.to-increase.com for an overview of the architectural changes. In subsequent posts we will present details on the product and scenarios for integration. Scrum and the tight integration between Team Foundation Server and Dynamics NAV allow us to achieve impressive results with a small team.
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.
Update: I removed the images from the blog and uploaded a zip file with all images.
Extract the zip file to a local folder and use the windows search options to find the appropriate images.
Implementing Team Foundation Server in your Microsoft Dynamics NAV environment often starts with version control. Since NAV does not have a native integration with TFS it gives some challenges. The most important one is: what is the best structure for my source code in Team Foundation Server? The Branching Guide of the ALM Rangers is a starting point for the proper strategy.
In Team Foundation Server, your source files are stored in a folder structure. This folder structure is created at the server. While working with the source files, however, a local version is used. The structure is important since this will be used throughout the development process. What is a good practice for such a structure?
I would like to share the branch strategy we implemented in our NAV development teams. In our development team we only develop standard solutions comprising both NAV and .Net technology. There are two formal release moments per year which we have to support. We are following the scrum methodology with an iteration interval of two weeks. New features are often developed in parallel. This is our branching strategy:
In Team Foundation Server this results in the following source control structure:
- The name of the Microsoft Dynamics NAV Product / Solution (which incorporate both NAV and .Net).
- Microsoft Dynamics NAV Release; we base our solutions on a particular Microsoft Dynamics NAV release.
- The localization of the Microsoft Dynamics NAV code.
- All Microsoft Dynamics NAV Objects are stored in the Objects and Unit Tests folder.
- Each release (1201 in this example) is branched from the main branch. This allows us to merge bug fixes into the different release branches and keep track of them.
In the past two years I’ve seen different branching strategies applied on NAV development. One thing became clear: keep it simple! There are costs related to each branch level since each level has to be maintained. Costs in the sense of complexity and time. Check out the Branching and Merging Primer for a number of branching Anti-Patterns that should be avoided at all costs.
Some best practices:
- Only include necessarily objects in your source control folder. It is, for example, not a good practice to include all NAV objects in your source control folder. Large projects have a negative impact on the performance.
- Be conscious in checking in completed changes only. This gives you traceability throughout your branches. Never check in code which is not completed or which does not compile.
- Pay special attention to the localization aspects of your solution since this is increasing the complexity significantly.
- Define clear responsibilities and ownership for the different branches.