Automating Continuous Integration

[Daklu]

When building large apps continuous integration helps ensure you're not breaking your executable when you check in new code. I've seen posts indicating some of the larger Labview shops do this. My question is how would I set up a system to automate the builds? Eventually I'd like a system that monitors the repository, automatically builds new code, and fires off blamemails when the build breaks.

• Do you have a dedicated build machine? If so, does it require its own Labview license? (I haven't seen anyone refer to a separate LV tool that just does builds, so I assume it does require its own license.)
• Are your builds automatically triggered when code is checked in or do you have to invoke it manually somehow? How would you set up a system to monitor your repository, and which scc system do you use?
• Are there any command line utilities for executing builds? Do you have to open a LV project and use scripting?
• Do your builds automatically run unit tests you have created?

This is just an idea I've had floating around in my head for a while. I'm nowhere near close to implementing it, but I'd like to get some idea of what's possible and how much work it would take.

[Yair]

I don't do this myself, but Justin's post here might help you - http://blog.jkisoft.com/jki/can-you-build-your-application-in-one-click/

Also, you can open up the OpenG builder to see how it calls the NI app-builder and you can look at the app-builder VIs yourself.

[jdunham]

That's a great topic. We are doing automated builds. Rather than running on every check-in, I have designed it to run every night, and it exits quickly if there are no checkins. However, I am currently only running builds on demand.

The build system has a couple purposes:

• making sure the builds are very consistent.
• keeping our development machines available, since validation and building is taking several hours
• configuration control: nothing extra or new (i.e. driver updates) is installed on the build machine without documenting it, and there is no way for code or any other dependency to be on the machine except via an installation or an SCC checkout.
• options: we can build off different SCC branches, select a subset of the build specs, and apply different conditional disable symbols

We were running this on a dedicated workstation, but we started using the machine for other tests, and had some issues with LV upgrades and configuration management, so I am moving the builds to a dedicated virtual machine.

As far as licensing, I have been told by local sales reps in the past that the intent of NI's licensing is to make sure that each developer uses a purchased copy of LabVIEW. Since we comply with that, and since my builds are taking huge amounts of time, I don't have any qualms about another LV installation onto a VM.

Another thing to consider is your source code control workflow. Currently most of our development takes place in the trunk, since merging is so awful and difficult, and we are careful to minimize conflict. Now that LV2010 allows you to store compiled code separately, merging should be easier, we could stop developing in the SCC trunk. I'd like to be keeping the trunk in a shippable state, and doing all development work in SCC branches, but we're not there yet.

I have a huge to-do list for the builds, including ever more automated testing, but it's a lot of work.

I would like to continue discussion of this stuff, but today is not a great day for me to write more.

[dannyt]

I think what we needs is a LabVIEW build plugin for Cruise Control

CruiseControl is both a continuous integration tool and an extensible framework for creating a custom continuous build process. It includes dozens of plugins for a variety of source controls, build technologies, and notifications schemes including email and instant messaging. A web interface provides details of the current and previous builds. And the standard CruiseControl distribution is augmented through a rich selection of 3rd Party Tools.

Dannyt