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 build.properties file needs to well, go away.  All this really means is taking build.properties and copying it to build.properties.template.  Then deleting build.properties out of source control.  Anyone getting our build our of source control will have to create a local build.properties 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 build.properties to build.properties.template.  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 build.properties.template to build.properties 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 build.properties.template becomes local.properties.template.  Now, I have to copy local.properties.template to local.properties 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='build.properties'/>
to
<property file='${env}.properties'/>

The cool thing is that I can add another file called (for example) 34SDK.properties 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 34SDK.properties 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:

3479c0f09a281e0fc8655d29fcba313b

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 build.properties file to get our build going again.

#Copy this file locally to local.properties 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

wrapper.dir=${basedir}/src/FlexAGSCI/html-template

version.major =0
version.minor=9
version.revision = 0
APP_TITLE = Flex Solution
APP_WIDTH = 100%
APP_HEIGHT =100%
locale = en_US
html.file=${deploypath.dir}/index.html
application.name=FlexAGSCI

#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 local.properties.template, 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.

Advertisements