Monthly Archives: September 2009

Continuous Integration with Flex, Hudson, and ArcGIS Server, Part IV

(Part 1, Part 2, Part 3, Part 5)

(Note:  I have started moving our builds to rake, the Ruby build DSL.  It is, howyousay, fantastic.  I see more posts in our series….)

Now that the school year has begun, I can get back into this series.  Last we left, we had ant running the build and the scripts.  Now it’s time to make the build portable, which means that our file needs to well, go away.  All this really means is taking and copying it to  Then deleting out of source control.  Anyone getting our build our of source control will have to create a local file, complete with all the settings that make the build go.  This is a “best practice” and stops developers from overwriting each others’ properties when they check in the build file.

So, do that.  Rename to  If you ant build-all now, the build throws an error, something about ${wrapper.dir} not found.  That’s because the build couldn’t pull in the properties file.  Copying to fixes the build.  However, we aren’t done with the renaming.  I want to introduce the concept of build environments to my build.  That way, I can have different properties files for named environments.  I may want to set up different SDK builds, etc. as well, and environments will help me do that.  All I need to do is add a property to the top of the build.xml file to hold my environment name.  It looks like:

<property name="env" value="local"/>

This means that, by default, I’ll be running in the local environment.  This also means that becomes  Now, I have to copy to to get the build going.  Another change to the build.xml file is to the line that pulls in our properties file.  It changes from:

<property file=''/>
<property file='${env}.properties'/>

The cool thing is that I can add another file called (for example) that points to the Flex 3.4 SDK.  Then to run that build, I can write:

ant build-all -Denv=34SDK

and it will overwrite our env variable and look for a file.  Flexibility is fun.

The SCMelephant in the Room

Up to this point, I have committed a cardinal sin.  No source control.  I know, bad developer.   However, I want to get the directory structure set up in a more CI friendly manner before I involve an SCM, so there is a method to the madness.  Let’s do that now.  There are roughly 1, 233, 443 articles on a developer’s workspace or CI directory structure.  I am going to use one that I’ve borrowed (and slightly modified) from Vish.  He is smarter than me, so it must be the way to go.  Here is the structure, in pictures:


You can ignore the .metadata folder, as that is a Flex Builder thing and I won’t put it in source control.   The build folder will hold the output of our build, docs is self-explanatory, src is where our Flex Builder project lives, and tools holds stuff we need to run the build.  In this case, we need the FluintAirTestRunner.exe, which I’ll copy into my tools dir.  The build file lives in the root of our project space, which means it has moved up relative to the Flex Builder project.  We need to change some things in the file to get our build going again.

#Copy this file locally to and change below for your env

# change this to your Flex SDK directory path
FLEX_HOME=C:/Program Files (x86)/Adobe/Flex Builder 3/sdks/3.2.0

# this points to your project's src directory
# {$basedir} is a default variable that can be used in any Antscript
# and it points to the project's root folder [ flex_ant_pt1_Tasks ]
# in this case
srcpath.dir =${basedir}/src/FlexAGSCI/src

# points to the project's libs directory
libs.dir =${basedir}/src/FlexAGSCI/libs

# this is the folder we want to publish the swf to
deploypath.dir = ${basedir}/build


version.major =0
version.revision = 0
APP_TITLE = Flex Solution
APP_WIDTH = 100%
locale = en_US

#Fluint vars
fluint.dir = ${basedir}/tools/FluintAIRTestRunner
report.dir = ${deploypath.dir}/reports

Now, running ‘ant’ at the project space root builds the project, and running ant test builds the test module and runs the test.  We copy this file to, and we are ready to import this project into source control.

I found a couple of posts that show how to import an existing directory into Subversion and make that directory your working copy, which is snazzy. It’s all here.  If you know anything about svn, that is a pretty straightforward post.

That’s that.  We are now ready for Hudson.  in the next post, we’ll get Hudson up, running, building our stuff, and running our test.