The Build Process

A good build process is more than just a script for compiling software. Instead, a build process performs and automates many of the common activities on a project. Examples of common activities include the following:

• Retrieving code from source control

• Installing the correct versions of libraries and software

• Compiling application libraries and components

• Running automated test suites

• Generating Javadocs

• Packaging components and libraries

• Setting up development and test environments, including updating database schemas and creating test data

• Deploying applications into a development environment

• Creating versioned releases of software components

• Deploying releases into a test environment

Having a ready-made build process in place before a project commences is a major time-saver. Build processes are sophisticated pieces of software that require careful design, construction, and testing. Consequently, investment in the development of build processes that are reusable between projects is a key factor in the makeup of a company's adaptive foundation for rapid development.

The next sections offer some guidelines for creating a build process that is conducive to the practice of rapid development.

Designing a Build Process

Like software systems, build systems require careful design. Regardless of the type of software under development, the requirements for a build system tend to be common between projects. Here is a summary of some of the main requirements:

Accurate.

The build process must be consistent between builds, producing the same result from a given set of source files for all developers on the team.

Rapid.

With builds running frequently, the process must be streamlined to ensure undue time is not lost waiting for the process to complete.

Automated.

All steps of the build process must be under the control of a suitable build tool that ensures the entire build can be automated. If developers are required to undertake manual steps, such as copying files or building individual modules, then the possibility of introducing build errors into the process is increased. Furthermore, manual scripts cannot be set up to run as scheduled tasks that can operate overnight.

Standardized.

How the build process is used should be consistent across projects and within teams.

Parameterized.

A build for a developer is likely to be subtly different than a build destined for a formal test environment. These differences could be compiler options or the omission of build steps. The build process must be able to generate a consistent release for each type of environment.

Maintainable.

Build environments have a tendency to increase in size and sophistication to the point that maintenance becomes a major headache, not to mention a black hole for lost time. The build system must be simple enough to be easily maintained yet capable of handling complex build tasks. Unfortunately, these two requirements are not complementary.

These requirements are common to most software projects. The development of enterprise-level software introduces a further set of requirements peculiar to the J2EE platform.

J2EE Build Requirements

The build process for a conventional Java-based application often builds only a single target, thereby making for a simple build environment. Unfortunately, a J2EE application is not so straightforward; it involves numerous intricate steps to generate multiple targets.

Unlike its J2SE counterpart, a J2EE application comprises a set of components, which collectively make up the whole application. Each component can have vastly different build requirements. EJB components require specialized compilation tasks for the generation of stub and skeleton implementations. Code generation tools such as XDoclet are becoming increasingly popular for the effort they save, but add additional steps and complexity to the build process.

XDoclet is covered in Chapter 6.

In addition to these specialized tasks, J2EE components require packaging. EJB components are wrapped in JAR files, and Web applications are packed in a Web archive (WAR) file. Finally, all components can be bundled in an enterprise resource file (EAR), the format recommended for J2EE deployments by application servers.

To summarize, a J2EE build typically includes the following tasks, which are additional to traditional Java builds:

• Execution of code generators

• Component-specific compilation, such as for Enterprise JavaBeans

• Packaging, for example, in JAR, WAR, and EAR files

• Deployment

All of these tasks devour time. Packaging, which requires moving files around the file system into a structure where they can be bundled into a format ready for deployment, is a particularly time-consuming process. Likewise, the process of deploying components to the server and placing them in an executable state is also potentially time consuming.

Shortening the length of time spent building and deploying is a case of reducing the amount of work the build system has to undertake. This gives rise to the concept of a build system capable of performing minimal builds and minimal deployments. We consider each concept in turn.

Minimal Builds

Generating source, compiling code, and packaging binaries into JAR files are all resource-intensive tasks. If the number of times these tasks have to be performed as part of the build can be reduced, savings in build times result.

Achieving these savings involves ensuring the build system can undertake incremental tasks, building only those components impacted by a particular code change. Therefore, if a source file is changed, the build system should not have to regenerate the full system. Instead, it should be able to determine from dependency information those components affected by the change, and accordingly build, package, and deploy only those modules that are affected.

Minimal Deployments

Minimal builds are only part of the story. It is also necessary to consider how a built application transitions into a state in which it can be run and tested. For J2EE solutions, this involves deploying components to the application server.

A minimal deployment approach looks to reduce the total number of steps that must be taken by the software engineer in order to deploy a change to the server. A typical worst case is that the server must be stopped, the entire application redeployed, and then the server restarted. This type of delay is unacceptable. Thankfully, most J2EE application server vendors acknowledge the importance of being able to turn around change quickly and efficiently, so they offer support for the hot deployment of applications. The practice of hot deployment requires further explanation given its importance to the build process.

What Is Hot Deployment?

Hot deployment is a concept embraced by most application server vendors and refers to the ability of the server to deploy an updated J2EE application into a live environment without having to shut down either the server or the running application.

For a production system, hot deployment has obvious benefits for system availability. For development teams, however, we require a slightly different form of hot deployment that is perhaps better called automatic deployment.

This concept has the application server continually polling for new files. On detecting a new file, the application server immediately loads the change and integrates it into the current application.

Warning

Automatic deployment is unsuitable for a production environment because the need for the server to poll its deployment directories continually is an unacceptable performance overhead.

In a fast-paced development environment, this functionality is a major timesaver for the software engineer, as no manual steps are needed for the application server to apply the software changes other than deploying the changes to the server.

Automatic deployment is a proprietary feature and is not covered by the J2EE specification, which only stipulates the deployment of EAR, WAR, JAR, and RAR files. Application servers, such as WebLogic from BEA, have gone beyond the J2EE specification and provide support for the deployment of applications in an expanded, or exploded, format rather than an archive file. This approach, which BEA recommends for deployment to its server, provides support for the minimal deployment approach.

WebLogic server supports automatic deployment if the server is running in development mode. This is achieved by setting the system property -Dweblogic.ProductionModeEnabled to false.

You must check the details of your particular application server to determine what it provides in terms of minimal and hot deployment capabilities.

Having covered some of the main requirements for a build system, we can now look at producing the build process itself. For this, we need to adopt a suitable build tool.