Automating the Build Process – Part 1

Improving the work flow in the development of Flash applications is something that has been in my mind for some time now, specially after seeing some presentations on the subject at Max Barcelona.

Usually the applications are not big, and are developed by a single programmer in less than a month, so they are manageable, but when a big one come along chaos is installed.

Up until recently, every application developed was compiled (built) in the programmer's computer using Flex Builder. If, for some reason, another person had to do some changes and generate a new build, he would be, in lack of a better word, screwed. To make things worse, all the source code (actionscript classes) is in Subversion but all the graphical elements are in Adobe's Version Cue Server (for the designers).This means that you have to:

• get the source from the subversion
• Get the .fla from Version Cue and compile an .swf or .swc
• Place the .swf or .swc inside the project's folder
• Discover which libraries the project uses
• ...

There are many things wrong in the way we work, So we decided it was time to make some changes. After this "revolution" we hope to get on track. Some implementations are obvious and can should be used by everyone, others are more subtil and will only make sense in our work environment.

There are some great resources available out there. With this series we just want to describe in a detailed way all the steps we took to automate our build process

Structure your Flex Projects

The first thing we did was create a "structure template" for all our flex projects (this is one of the obvious ones).

This should look pretty obvious. The folders are all created manually after creating a new actionscript project inside flex builder.

src - This folder holds all the classes used in the project. Make sure that when you create a new project you specify src as your Main source folder.

externals - This was one of the __biggest__ improvements in our work flow. (read below)

fla - This folder holds all the designer's FLA files. We make sure the export path on those files point to ../assets/

assets - Holds all the assets needed by the application, like images, swf files, videos... Because the assets folder is not inside the main source file, all the references must be made using the ../ notation. (see deploy)

docs - Holds the documentation for the project as well as ASDOC generated htmls docs for the API

lib - Currently I'm only using this folder to store the "flexTasks.jar" file needed by ant to compile the project.

bin - This is the folder used by Flex Builder and ANT to generate the swf file into.

deploy - This is where we create the structure for the application deployment. Because the final swf file will look for assets in ../assets we need to make sure the swf file is one level down the hierarchical directory structure.

Use svn_externals

"Sometimes it is useful to construct a working copy that is made out of a number of different checkouts. For example, you may want different subdirectories to come from different locations in a repository, or perhaps from different repositories altogether" in svnbook

We always use a couple of libraries in our projects. Stuff like our own internal classes, Tweener or Papervision. Before using externals, some developers in the flash team had the library classes stashed away somewhere in their hdd to centralize information and avoid replication, while others copied all the library classes into the main source folder every time they created a new project. Both approaches get the job done but, they both have flaws.

In order to successfully compile the project you had to have all the classes (dependencies) installed on your machine. This was troublesome most of the times when trying to compile the project in a machine other than the one used to program the application.

With svn_externals we don't keep copies of the library classes in our hdd. Every external class library has it's own svn project (prefixed by external). This means that in our svn server we have a project named external_papervision, or extrenal_Tweener. Having the libraries code in our svn server allows us to keep track of versions and we can easily specify which version we want to use in a given project.

We use externals not only for library classes, but for any external tool needed to compile the project (like ant).With svn_externals we guarantee that the project will build anywhere, anytime (because all the dependencies are taken care of by svn_externals).

Read how to do it in the svnbook