A modularized Flex application consists of several Flash Builder projects. Each of the individual projects contains the build.xml file that performs the build and deployment of this project. Additionally, one extra file should be created to run individual project builds in an appropriate order and to deploy the entire application in some predefined directory, for example, C:\serverroot as described in the section Flex Developer’s Workstation.
Such a main build file should account for dependencies that may exist in your project. For example, the application that produces the main .swf file can depend on some libraries that are shared by all modules of your application. Hence the main Ant build file needs to have multiple targets that control the order of individual project builds.
In some cases, for auditing purposes, if a build task depends on other builds—i.e., .swc libraries—all dependent builds should be rerun even if the compiled version of .swc already exists.
Apache Ant is a popular Java-based tool for automating the
software build process. You can run Ant builds of the project either
from Flash Builder or from a command line. To run the build script from
Flash Builder, right-click on the name of the build file, such as
build.xml, and choose the Ant Build
from the pop-up menu. The build will start and you’ll see Ant’s output
in the Flash Builder console. To build your application from a command
line you can use a standalone Ant
utility. To be able to run Ant from any directory, add the
bin directory of Ant’s install to the
PATH environment variable on your
Ant uses the tools.jar file
that comes with the Java SDK. Modify your environment variable
CLASSPATH to include the location
of tools.jar on your PC. For
example, if you did a standard install of Java 6 under MS Windows, add
the following to the
To run the Ant build from a command line, open a command window,
change directory to the project you are planning to build, and enter
ant, as in:
In addition to the developer’s workstation, all build scripts need to be deployed under a dedicated server, and developers should run test builds first on their local workstation and then under this server.
Writing Ant build scripts manually is a time-consuming process. To help you, we created Fx2Ant (it comes as a part of Clear Toolkit; see http://sourceforge.net/projects/cleartoolkit/). After installing the Clear Toolkit Eclipse plug-in, just right-click on “Flash Builder project” and select the menu Generate Build Files, and within a couple of seconds you’ll get an Ant build script that reflects all current settings of your Flash Builder project.
There is also an open source project called Antennae that provides templates for building Flex projects with Ant. Antennae can also generate scripts for FlexUnit. It’s available at http://code.google.com/p/antennae/.
Maven is a more advanced build tool than Ant. Maven supports builds of modules and creation of applications that use the Flex framework RSL. It works with FlexUnit and ASDoc. If your organization uses Maven, get flex-mojos at http://flexmojos.sonatype.org/. This is a collection of Maven plug-ins to allow Maven to build and optimize Flex and AIR .swf and .swc files.
You can find an example of configuring a Flex/Maven/Hibernate/Spring/BlazeDS project at http://www.adobe.com/devnet/flex/articles/fullstack_pt1.html.
Introduced by Martin Fowler and Matthew Foemmel, the theory of continuous integration recommends creating scripts and running automated builds of your application at least once a day. This allows you to identify issues in the code a lot sooner.
You can read more about the continuous integration practice at http://www.martinfowler.com/articles/continuousIntegration.html.
We are successfully using an open source framework called CruiseControl for establishing a continuous build process. When you use CruiseControl, you can create scripts that run either at a specified time interval or on each check-in of the new code into the source code repository. You may also force the build whenever you like.
CruiseControl has a web-based application to monitor or manually start builds (Figure 4-7). Reports on the results of each build are automatically emailed to the designated members of the application group. At Farata Systems, we use it to ensure continuous builds of the internal projects and components for Clear Toolkit.
IT shops that have adopted test-driven development can make the build process even more bulletproof by including test scripts in the continuous integration build process. If unit, integration, and functional test scripts (which automatically run after each successful build process) don’t produce any issues, you can rest assured that the latest code changes did not break the application logic.
Hudson is yet another popular open source continuous integration server.