What is Continuous Integration and how do I use it with ActionScript or Flex applications?

Posted by Luke Bayes Fri, 08 May 2009 17:00:00 GMT

We recently got a question on the Sprouts Group about Continuous Integration (CI) and I thought I’d try to give it a quick explanation here.

The idea behind Continuous Integration is that you have a machine somewhere on the network that will check out, compile and test your application after almost every check-in. Whenever failures are encountered anywhere in that process, the entire team is notified. This helps us discover unexpected regressions or injections early which helps us pinpoint and address their root causes more efficiently.

This process can be useful in any project, but is especially helpful when working with teams that are all checking into different components of a larger project.

There are essentially three major problems when attempting to introduce ActionScript or Flex applications to typical CI systems:

• The Flash Player requires a visual window manager to execute your test harness (Usually X-Windows on Linux)

• The Flash Player does not give us the ability to capture all runtime exceptions, and when an uncaught runtime exception is encountered in the Debug Flash Player, a GUI dialog box is presented that must be manually clicked with a mouse in order to continue or abort execution. This can hang a typical CI set up, and result in an unhelpful “execution timeout” failure.

• It can be challenging to get a Linux machine properly configured to compile your ActionScript or Flex application, run your test harness, and collect trace output and error messages.

Sprouts does not attempt to address complicated and varied system configuration problems related to X-Windows, so you’ll need to figure that out for your system. The main idea is that the user account that executes your test harness must have access to a running window manager. This is a requirement of the Flash Player, not Sprouts.

The second major issue – that of uncaught runtime exceptions – is handled by Sprouts because we can use the Flex Debugger together with the Debug Flash Player to execute your application and the Flex Debugger actually pauses execution before launching that annoying GUI pop-up that we see in Debug Flash Player all over the internet. Because we use the Flex Debugger, we also collect and report additional information about what is going on in the runtime if an exception is encountered. It’s important to note that even though this product was inappropriately named ‘Flex Debugger’, it also works beautifully for ActionScript only projects.

The third item is where Sprouts really shines. Because Sprouts manages most of it’s own dependencies on OS X, Windows XP/Vista, and Linux, all you have to do is log into your CI machine (as the CI executing user) using any standard terminal, check out your project from version control and run rake cruise. That’s it. Assuming you have Ruby and RubyGems installed, Sprouts will download and install everything you need to compile and run your project on that machine, in the user home for that user.

To summarize, you should be able to take the following steps to get Continuous Integration going for your project.

1. Get a standard CI server set up. I like CruiseControl.rb, but lots of people use Cruise Control
2. Ensure that your CI user account has access to a window manager
3. Check your project into a remotely-accessible version control system (Subversion or Git ?)
4. Log into your CI machine using the user account that will execute your CI tasks
5. Change into any arbitrary directory in your user home
6. Check out your entire project
7. Run rake cruise against the directory that has your rakefile.rb
8. Set up your CI configuration to point at your project repository and execute rake cruise
9. Set up your CI configuration to collect “artifacts” from bin/* and AsUnitResults.xml
10. Log into your server and look for the green bar!