Tag Archives: Version Control

New Team Foundation Server Connector : Looking for Beta Testers

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 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.

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.

Which Branching Strategy fits best in a Microsoft Dynamics NAV environment?

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:

  1. The name of the Microsoft Dynamics NAV Product / Solution (which incorporate both NAV and .Net).
  2. Microsoft Dynamics NAV Release; we base our solutions on a particular Microsoft Dynamics NAV release.
  3. The localization of the Microsoft Dynamics NAV code.
  4. All Microsoft Dynamics NAV Objects are stored in the Objects and Unit Tests folder.
  5. 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.

Can you start with Agile in your NAV development process today?

In the past weeks I got several questions about how to implement Agile in your NAV development team. This is not an easy question since the answer depends on your organization and on your team.

Define The goals: The most difficult aspect of implementing Agile is the organizational change. Following the agile practices requires a mind shift in the first place. Why do you consider to implement agile? Is it because everybody is doing it or is it because of the value it adds for you? It makes good sense to start with a definition of the goal you try to achieve. I recommend this  article to get started. Once the goals are clear you can proceed but keep in mind:

Think Big, Act Small

Version Control: So, what would be a logical next step? This blog is all about Team Foundation Server for Microsoft Dynamics NAV. It will become difficult to use Team Foundation Server for you scrum process without proper version control and build automation. I suggest to start with version control first. This will make you familiar with the Team Foundation Server environment. In future posts I would like to share information about how to enable version control for Microsoft Dynamics NAV.  You need the  To-Increase Source Control plugin for Microsoft Dynamics NAV to get started.

Build Automation: Once your version control is complete you can start thinking about Build Automation. Build Automation requires a one-time installation and configuration at Team Foundation Server and you’re good to go. The process itself is more difficult. Building software is one thing, embedding it in your process is something different.

Adopt Scrum: If your version control and build automation are up and running you can start with optimizing your process. I recommend the excellent presentation of Aaron Bjork, which really helped me understanding how scrum is provided by Team Foundation Server.

One of the good aspects of agile is that it identifies these issues and allows you to improve your process after each sprint. And one of the good things of Team Foundation Server is that it allows you to change the configuration and optimize it continuously.

How to setup and use Build Automation for Microsoft Dynamics NAV?

With Team Foundation Build, you can create build definitions to automate compiling applications, running associated tests, performing code analysis, releasing continuous builds, and publishing build reports.

To build an application, you create a build definition to specify what projects to build, what triggers a build to run, what automated tests to run, and where to deploy the output. This information is stored in the data warehouse, from which it is retrieved when a build runs. After the build runs, data about the build results is stored back in the warehouse, where it is available to view through build reports.

The following illustration shows the three main phases of building an application:

Three phases of building an application

Since Microsoft Dynamics NAV is not provided with out-of-the-box Build Automation it might be a good idea to demonstrate how to set up a Build Configuration for Microsoft Dynamics NAV and how you use it in the process.

The Microsoft Dynamics NAV compiler requires specific settings. After selecting the appropriate template these settings become available. A Microsoft Dynamics NAV build requires the following parameters to be set:

  1. Database; One of the concepts of Continuous Integration (CI) is that you isolate your development from your build environment. That’s exactly what we do here. Each Dynamics NAV build requires a clean environment which means a clean database has to be restored. In our case we use the demo database from Microsoft as the reference.
  2. Dynamics NAV Version; which Microsoft Dynamics NAV binaries have to be used for this build.
  3. Reference Objects; in many cases you might need one or more other NAV solutions which have to be imported in your reference database before you run the build.
  4. Microsoft Dynamics NAV Object Filter; the deliverables of a build are one or more Microsoft Dynamics NAV object files in text and fob format. The name of each filtered set can be specified.
  5. Build Details; the Build Number is written to a specified codeunit (just like you have in Codeunit 1) which makes it possible to track the build details at runtime.

Your Dynamics NAV development team is now ready to use Build Automation. One thing left: how do you unleash the beast? Well there are various ways how you can do that. One of the good things of Team Foundation Server is that it has various interfaces; the most important options are:

With the Team Explorer:

And with Team Web Access:

After queuing the Build it becomes pending:

Once a build is ready it appears under the Completed builds. Team Foundation Server keeps track of the complete history of each Build Configuration:

And the result of each build can be viewed at any moment:

Build Result

A successfully completed build gets associated with Change Sets and Work Items which gives you complete traceability from a shipped solution to the  code. There is much more to say about this, like reports, dashboards and sprint planning.

Build Notifications are provided out of the box. You can get all sorts of alerts if someone breaks a build or if a build completed without any error.

Conclusion: is it easy to implement Build Automation in a Microsoft Dynamics NAV team (assuming you have the To-Increase Build Template for Microsoft Dynamics NAV installed). Once configured, it is easy to set up build configurations and show builds. The process part, however, is more difficult. It requires you to work in a different manner than you are doing today. Instead of focusing on the Microsoft Dynamics NAV Object Designer with its whims you have to think from the agile process. That means no messing around with individual fobs but complete builds of your solution. Build Automation will significantly improve your flexibility and quality and will make your NAV development more fun.

Build Automation for Microsoft Dynamics NAV – a soap or reality?

In my previous post the concept of Continuous Integration has been introduced. In this post I’d like to zoom in on the Microsoft Dynamics NAV specific enhancements of Build Automation.

I recommend this video if you want to get an overview of Team Foundation Server Builds.

Team Foundation Server provides scalable solution for Build Automation. It is quite easy to scale up if you need more build power. In our case parallel processing was an important requirement. Luckily this is provided out of the box. So what server park do you need to facilitate NAV builds? I don’t have much reference material at the moment so I’ll take our scenario as an example: for Microsoft Dynamics NAV solutions with object collections varying from 1000 to 2000.

We have the following configuration for our Microsoft Dynamics NAV builds:

  • 1 Team Foundation Application Server; this server hosts our Microsoft Dynamics NAV Team Project Collection.
  • 1 Build Controller; each Project Collection has one Build Controller.
  • 2 Build Machines; one Build Machine for all versions older than Microsoft Dynamics NAV 2103 and one for Microsoft Dynamics NAV 2013 (and higher…:))
  • 6 Build Agents; a build agent runs the build workflow. We have four of these guys but we can easily increase the number of Agents. We can run two builds in parallel on each Build Service.

So how do you actually use the system in your development process? The first thing is that you have to create a New Build Definition from the Team Explorer.

This opens the Build Definition window in which you can specify the properties of the build. The Microsoft Dynamics NAV enhancement can be activated by selecting the appropriate Build Process Template.

Selecting the Microsoft Dynamics NAV Build Process Template enables the Microsoft Dynamics NAV parameters. After specifying these parameters you are ready to rock.

Conclusion: Build Automation for Microsoft Dynamics NAV is reality and can be enabled without tampering with you Team Foundation Server installation. Just follow the standard installation instructions and you are almost there. If you install the Microsoft Dynamics NAV build template (which can be obtained for a fair price at To-Increase) you are good to go.

Imagine how much power this will add to your development team and how much easier it will be to create shipable units of your Microsoft Dynamics NAV solutions or customizations. Build Automation will definitely change the way you ship your Microsoft Dynamics NAV solutions and will increase your productivity drastically. No, I am not a sales guy and Microsoft does not pay me for telling enthusiastic stories about Team Foundation Server…. 🙂