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