Tag Archives: Build Management

NAV Test Automation and Build Automation

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.

2013-04-04_09h37_58

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.

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

Continuous Integration: Build Automation for Microsoft Dynamics NAV

In my previous post I shared our concept of Agile for Microsoft Dynamics NAV: adapt Microsoft Team Foundation Server to Microsoft Dynamics NAV by using extensions. This allows us to utilize all the Team Foundation Server capabilities. We didn’t implement this concept in one day. We spent a lot of time on understanding the concepts of TFS and mapping them on our Microsoft Dynamics NAV domain. Currently we have two Microsoft Dynamics NAV extensions for Team Foundation Server: Version Control and Build Automation. I would like to write some articles about those extensions and will start with Build Automation.

Since we don’t have the concept of builds in our Microsoft Dynamics NAV domain it makes good sense to start with some theory. Build Automation is an essential concept of the Continuous Integration  concept. So, does this concept mean?

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day.

Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

(Martin Fowler, co-author of the Manifesto for Agile Software Development).

Martin Fowler has the following breakdown of practices for continuous integration:

  • Maintain a single source repository.
  • Automate the build.
  • Make your build self-sustaining.
  • Check in at least once a day.
  • Build each check-in on the CI server.
  • Keep the build fast.
  • Test in a clone of the production environment.
  • Make it easy for anyone to get the most recent executable.
  • Always be aware of what is happening.
  • Automate deployment.

This sounds reasonable, right? But How can  apply these practices on our Microsoft Dynamics NAV  eco system? Well, you cannot: the development platform we have today is focused on the developer and not on the process. But, the good news is that these practices are provided with Team Foundation Server out-of-the-box: Team Foundation Server 2010 provides a robust and fully featured build automation server. You can customize Team Foundation Build and configure triggers for manual build, continuous integration, rolling builds, gated check-in, or scheduled builds. The gated check-in feature helps teams working in the same branch to prevent costly and time-consuming build breaks by testing code in isolation before it goes into the full repository. In addition, support for Windows Workflow based builds with powerful features like build queuing and build agent pooling enable you to easily customize, manage and scale out your build environments.

As you can imagine the standard Build Automation is optimized for .Net development. But luckily it has been provided with extensions which allows you to have a specific build flow for other platforms like Dynamics NAV.

Let’s take a look at the normal build workflow for .Net projects; The standard build process carries out the following steps:

  • Create a clean isolated environment in which the build is ran.
  • Download the source code from the source code repository.
  • Update the version information.
  • Compile the source code.
  • Run the unit tests.
  • Copy the compiled code to a network location
  • Cleanup.

When working on the build automation at To-Increase we took these steps as the starting point and asked our self the question: what is specific for NAV? 

  • Version information of Microsoft Dynamics NAV is very specific; we cannot use the standard system here.
  • Code Compilation requires the Microsoft Dynamics NAV Development Environment and does not fit in the standard build template.
  • The Microsoft Dynamics NAV testability framework requires a Microsoft Dynamics NAV runtime environment.

We have addressed these areas one by one and were to include them all in a Microsoft Dynamics NAV build template for Team Foundation Server. As a result we can use all the build capabilities of Team Foundation Server and applied the continuous integration practices at our NAV development team. As you can imagine this was really a break trough. Automated Builds are a key element in our development process, both from quality and productivity perspective. In future posts I’d like to explain more about the details of Build Automation for Microsoft Dynamics NAV.

For now there is one question left: Is Build Automation only useful for big development projects or for ISV solutions? The question is No. It has been proven that the concepts of builds works pretty well for small customization projects as well. But one thing is for sure: adopting Agile in your development has impact on the development user experience. If you follow the agile practices which are out of the box provided by Team Foundation Server you’ll be surprised about all the possibilities.

Conclusion: Enabling Team Foundation Server Build Automation for Microsoft Dynamics NAV brings the full power of this system to the Microsoft Dynamics NAV development. It is a key element for a succesful implementation of Agile in your team. Continuous Integration helps you in improving the quality of your solutions, it optimizes the efficiency of your team and provide a transparent information flow to all stakeholders.

The marriage of Microsoft Team Foundation Server and Microsoft Dynamics NAV

I think the time is there to share the core concept of this blog. Like mentioned in earlier posts the goal of this blog is to  inspire Microsoft Dynamics NAV professionals to adopt Agile in their development processes. Agile is a popular topic these days. Most information, however, is focused on other platforms, like .Net development. We noticed there is still a gap between those platforms and Microsoft Dynamics NAV. That is the goal of this blog in a nutshell.

As you may expect from good software developers we have an architecture for the articles posted on this blog. We are very much in favor of eating our own dog food which means we use real  examples with live code. In previous posts you probably saw some screenshots of Team Foundation Server provided Microsoft Dynamics NAV artifacts. The time has come to share this architecture with you.

The concept is simple: we want to apply the standard process template for MSF for Agile Software Development v5.0  to our organization. This template has been created by seasoned  experts and its current version is 5.0. One of the authors of this template (Jeff Sutherland) wrote an excellent article about the details of Agile Principles and Values. What if we try to apply these principles on our Microsoft Dynamics NAV domain? Obviously we want to achieve the same goals, even though we have different tools.

So far so good but we have our Microsoft Dynamics NAV Development Environment with its whims. How realistic is it to apply these principles on Microsoft Dynamics NAV? This question has been on our mind for a while. After researching and discussions we ended up with the following solution: we follow the standard Agile template  and adapt it with Microsoft Dynamics NAV by using the extensions of Team Foundation Server. This effectively means we adapted Team Explorer and Team Foundation Build System with Microsoft Dynamics NAV. As a result we are able to unleash the full power of Team Foundation Server, without requiring any customization of the process or Microsoft Dynamics NAV.

Because of this concept we are able to have one process for both .Net and NAV and AX development. Which is no luxury these days since more and more Microsoft Dynamics NAV solutions depend on .Net components.

I hope I did not scare you by sharing this concept. Remember it took us two years to implement this. The organizational change is the most difficult one. Agile is not the magic word which solves all issues but it surely identifies them. Another  good aspects of agile is that you can take small steps to improve. That is exactly what we did: we started with version control, then build management and after that we implemented scrum. Recently we integrated the Microsoft Dynamics NAV builds with Microsoft Dynamics NAV Testability Framework. Yes we are in the process of continuous improvement right now. In fact, it only just begun :).