We’re doing a current project requiring continuous integration. We also maintain the SVN repo. There’s a lot here and you may/may not need all the pieces. We’re specifically doing headless Flex/DataViz Builds on Amazon EC2 Ubuntu with Hudson against a remote SVN repo on Assembla and have thrown in FlexPMD to see what it can add to our process.

First, some stuff I’ll assume you already have and know how to work with:

• EC2 machine running in the Amazon cloud. We’re using one of the Ubuntu disty’s. I’m going to assume you have all the necessary ports open for things like email and such.
• Hudson. We’re using version 1.326. We’ve used other CI tools but find Hudson to be very user friendly. You’ll need to have a servlet container ie Tomcat and you just pop hudson.war in and you’re ready to rock.
• Remote SVN. You can be using a local one, but. We’re using Assembla since it’s got all the stuff we need to do business in one place and it’s simple to use. Time is money.
• Java installed on your server. We’re using version 1.6.0_07

Stuff you’ll end up downloading/installing/configuring:

• Flex SDK
• Flex Dataviz components
• SVN client
• Ant
• Flex Ant
• Email

Step 1, Flex

We’re currently building with the latest stable build of Flex 3.4. Get yourself all logged into your EC2 account and let’s roll. I create a flex/3.4 directory and cd to that directory and then get the latest Flex rev. This is the latest URL:

wget http://download.macromedia.com/pub/flex/sdk/flex_sdk_3.4.zip

Let’s get the dataviz components as well since they’re a separate install

wget http://download.macromedia.com/pub/flex/sdk/datavisualization_sdk_3.4.zip

Oh yeah, and if you’re going to be doing unit testing, might as well get that sucker as well

wget http://download.macromedia.com/pub/flex/sdk/automation_sdk_3.4.zip

Great, so we have all the pieces we need so far. You’ll want to unzip and cp these to wherever you keep your software installs on the server. I’m no unix guru, but, near as I could find out, the common location is /opt.

So, create a /opt/flex directory and unzip the flex_sdk_3.4.zip files there. Then, copy the dataviz zip there and unzip it.

cp datavisualization_sdk3.4.zip /opt/flex

cd /opt/flex

unzip datavisualization_sdk3.4.zip

This will extract the following into the SDK 3 installation

1. datavisualization.swc into the frameworkslibs folder
2. datavisualization__3.0.9147.swz and datavisualization__3.0.9147.swf into the frameworksrsls folder
3. datavisualization_rb.swc into the appropriate frameworkslocale<locale> folder

Let’s make sure we put the Flex compiler on the class path. On our server, the default shell is bash. You’re setup may be different, but essentially, you want to find the properties file for you shell (I’m using /root/.bashrc) and add the following line to the bottom of it:

export PATH=/opt/flex/bin:$PATH

Now let’s test it. You may need to log out and then back into your shell. At the command prompt, enter mxmlc and hit return. You should see something like

Loading configuration file /opt/flex/frameworks/flex-config.xml

Error: a target file must be specified

That’s a good error. It means that the Flex compiler is now accessible on your system. If nothing comes back, you’re just at the command prompt, you may not be using the right shell properties file.

In order to build projects that use the dataviz components without having the watermark on your charts and graphs, you’ll need to apply a Flex license to the installation. You do this in the flex-config.xml file located in /opt/flex/frameworks. Towards the bottom of the file you’ll see some commented out xml for doing so:

<licenses>
<license>
<product>string</product>
<serial-number>number</serial-number>
</license>
</licenses>

Step 2, SVN

We are accessing an SVN repo on our Assembla account. The easiest way to make this happen from the EC2 is to just install SVN. So, from the command prompt:

apt-get install subversion

If you run into any errors, I always find it helpful to refresh the list:

apt-get update

If all went well, you should be able to log into your remote repo:

svn –username <your_username> –password <your_password> –no-auth-cache checkout <some_project_name>

If successful, you’re going to have a checked out version of some_project_name in your current directory.

Step 3, Ant

We’re going to be using Ant as our build process. It will called via a Hudson job. Let’s get and install Ant.

apt-get install ant

Once that completes, you should be able to type ant at a command prompt. If it installed successfully, you should see something similar to (unless there happens to be a build.xml file in your current directory):

Buildfile: build.xml

BUILD FAILED

This is good. We now have Ant installed. The only other Ant specific thing we’ll need to do is copy the FlexTasks.jar from your Flex SDK into your new Ant install.

Let’s find where Ant was installed. At a command prompt:

which ant

(which will most likely return)

/usr/bin/ant

Now, navigate to your Flex SDK Ant lib directory. The Flex SDK now contains the flexTasks.jar we need.

cd /opt/flex/an/lib

Now just copy this to the location of your Ant install’s lib directory (typical):

cp flexTasks.jar /usr/share/ant/lib

If you do not copy this file to the lib directory, you must specify it by using Ant’s -lib

option on the command line when you make a project.

Step 4, Setup Hudson Job

Plugins

I’m assuming you have a working familiarity with Hudson. If not, there’s a ton of info via your install directly and on the web. We have a few extra plugins installed. The Violations plugin is useful for code analysis via PMD files if you structure your ant files to use it. The Email Extension gives you a bit more flexibility than the basic email tool.

Configuration

Here’s a look at few items we needed in the Hudon configuration page to get things to work smoothly

Specify the Ant location on your server.

For the Extended E-mail Notification plugin. We’ve defined an email account on our system called hudson. We also use gmail for our corporate email. We’re essentially relaying to gmail which requires SMTP auth and SSL (note: we haven’t entered anything in the default Hudson E-mail section):

Job Setup

Go the usual steps of creating a new job. Here are the pertinent parts.

In Source Code Management, we’ll need to point to our remote SVN. When you click on the “?” next to the Repository URL, you will see the grey box and be able to provide login credentials to your SVN repo and test the connection:

We’re not going to specify any build triggers. The reason is that Assembla gives the ability to access the post-commit hook in SVN via their “Webhook” plugin. In that tool, all we have to do is specify the Hudson job URL and with each check in of code, the project is checked out, built, and success/failure notification sent to our dev group. This is the key to the ‘continuous integration’ aspect of this whole setup.

We do need to tell Hudson to use Ant to do the builds. We have a target in the build.xml file (that is in the root of our Flex project) called main.hudson. To be on the safe side, I’ve specified the full path to the build file. We specify the ant install we configured in the Hudson configuration page earlier. It would probably be helpful to give it more meaningful name like ‘ant_version_x’.

FlexPMD is another great tool we use that profiles your code based upon a bunch of best practices defined by the Flex group at Adobe. You can also specify your own criteria to use in the analysis. It’s worth checking out. Note the format of the XML filename pattern used. It took a while to figure that part out!

We configure the Editable Email Notification accordingly:

And that’s pretty much it. I’ll be pushing up a blog shortly that will walk through the whole ant build used for this project. It uses modules, all sorts of RSLs, FTP, and so on.

Happy Flexing.

Tweet This Post