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:
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:
- 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.
- Dynamics NAV Version; which Microsoft Dynamics NAV binaries have to be used for this build.
- 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.
- 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.
- 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:
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.