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.

Is Agile not important anymore?

You maybe wondered why there were no new posts in the past two months. Don’t worry, agile is still important and it is still possible for Microsoft Dynamics NAV. The past months were quite challenging from several reasons. Microsoft Dynamics 2013 came out and we are fully focussing on getting our solutions ready on the new architecture. Meanwhile Microsoft Team Foundation Server / Visual Studio 2012 came out. Windows 8 ….. In the same period I became father of a sweet little daughter… So, like I said: challenging times!

But I have many ideas for new posts. I really want to write a number of posts about developer isolation for Microsoft Dynamics NAV. Another interesting topic is the license change of visual studio: test manager is now part of the premium edition! If you have a msdn subscription this beautiful piece of tooling may be in your toolkit. I have been working on the testing part of our Agile process in the past months which resulted in a significant improvement of the process. This would not have been possible without proper version and build control which forms a basic element of our agile process.

Physics of Being Agile

Recently, with all those vibes about SCRUM going around in our organization, a couple of colleagues went for “Certified SCRUM Master” training, incidentally same person trained myself and one other colleague 6 months ago. I got a chance to talk to him over phone and was glad to accept his offer to be a guest speaker in his session. It was difficult to find what to talk, what was expected from me was to share how we are implementing it and our journey with SCRUM. However, understanding the nature of the training environment it was pretty clear for me to send a message to the audience, I just wanted to talk about what can be the real world implementation issues one can have with SCRUM or any other AGILE practise implementation in a place where such concepts are not known.

Jim Collins in his book “Good To Great” started off to explain what is the Physics of going from Good to Great. While trying to understand what he means I started to think Agile as Physics albeit Modern Physics. Why??. Because Classical Physics is governed by Laws, the very nature of Laws is their rigidity. And rigidity is something which is quite alien to Agile. In fact Agile Manifesto itself talks about Principles, which are not that rigid in nature. Try comparing this with Principles in Modern Physics, like the Heisenberg Principle of Uncertainty. Just like how we cannot determine the position and momentum of a particle simultaneously, I see some very similar striking similarities in software.

So what is uncertainty in software, we cannot easily and simultaneously predict the direction of the software and the time when that can be achieved. This very nature of software makes it more an Empirical Approach, rather than a Predictive Approach.

Next came, a statement which is quite close to my heart, this helps me measure the direction in which I am heading. Remember the book “The Goal” I talked about in my previous post. How about little Physics against your Goals? Smile

“Any action which is taking you towards your Goal is productive.“

“Any action which is taking you away from your Goal is counter-productive.“

What is our goal here? Our goal here is to be “Agile” so we measure our actions with the Agile manifesto’s principles, this helps us in understanding the Philosophy of Being Agile.

The last point(s) I talked about was the real challenges we face in our day to day implementation of SCRUM. Initially when I heard that it is not easy I was not believing it. But when we saw that it is hurting us back then I realised the challenges.

As an advocator of Agile practises you might face several of challenges, but I can make out only two :

  • People: It is hard to explain people the philosophy of Being Agile until they see it practically happening.  To make it happen you need like-minded people who should be willing to
    • Experiment, learn and experiment without fear of failing.
    • Fight for the cause, be in regular confrontation mode for the common goal.
    • Sacrifice their mediocrity for a greater good.
  • Organizational: Sometimes it is difficult to implement Agile because the scale in which the organizations want to implement it. That’s if they like it they want to implement it as a big-bang. But that’s not how you can implement Agile practises. These principles needs to be infused, SLOWLY….take small steps and show visible improvements.
      • Sometimes there are financial implications
      • Sometimes there are people waiting for decisions from top management
      • Sometimes there are timing issues, example you are already in between of a release, obviously you wont try your hands on new stuff which can jeopardise your current schedule.
      • Sometimes there are simply lack of proper engineering practises to deal with the shorter iteration philosophy of being agile.
      • and many many more..

I believe somewhere there are solutions, being with thinkers and innovators can definitely help in this case.

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.