This is the last installment in our AX Build Automation series. In part 1, we discussed how to install a continuous deployment software suite, in part 2 we discussed the classes we had to modify to harness the Startup Commands to prepare a modelstore, and finally today we will demonstrate how to automate it all together.
The majority of our work is done. All we need to do is develop a powershell script to call all of our commands, and perform a little validation. The script below works for default installations of AX 2012 R3, if your directory structure is different you’ll need to make some small modifications. You can also simply download the script here.
You’ll see the script has several logical sections around each command we are calling. In each case, it checks for warning output and error output. You can decrease your risk tolerance and throw an exception if warnings are found as well.
This makes use of the Startup Commands we created in the previous post, as well as AXBuild.exe for multi-threaded X++ compilations. All in all, on a moderate development VM this takes an hour or so for a full TFS sync, X++ compile, Database Sync, and full CIL generation.
Now that we have a workable script, it’s time to make use of it in TeamCity.
First, we’ll need to create a new Project with a new Build Configuration:
Above you’ll see we are using a customized build number format which includes a static 2.0 and is appended with the build counter plus the final changeset ID that triggered the build.
Here you see we have attached a VCS root connected with TFS. We use our building service account credentials, as well as specifying the branch we wish to monitor. We tell TeamCity how often we wish to monitor the branch for new activity.
Next, we add our powershell command:
You’ll see we have specified the runner type as Powershell. We could easily have broken down the script to smaller pieces as well and had several build steps. Perhaps for v2 =)
The bitness needs to match your installation of Windows that the build agent resides on, and you specify the directory in TFS where the powershell script resides. Finally, at the end you’ll see we use the ExecutionPolicy Bypass to skip powershell prompting for us to verify the validity of the script prior to executing.
Optionally, you can specify build triggers, so that perhaps only TFS check-ins with a certain comment kick off the build, while minor changesets do not. By default, all check-ins will trigger a build, based on how often TeamCity is monitoring the VCS root.
And that’s it! TeamCity will send an email digest of the particular files going in to the build, and you now have a modelstore ready for export and import to your production system.