Introduction

In most large-scale software development projects, multiple developers independently write numerous source code components, which must eventually be compiled, packaged, and delivered to testers or end users. The compiling and packaging process is of course commonly referred to as a software build. The success of a development project depends partly on the accuracy, reliability, and repeatability of the build process. Each build must use the correct versions of source code files, dependent library modules, and compile and assembly tools. The best way to ensure the accuracy, reliability, and repeatability of each build is to automate the build process. Build automation, however, requires its own set of scripts and batch files, and the complexity of this automation code often increases over time as application size and complexity increase. To address this challenge, this three-part article series describes an effective method of build automation using IBM ® WebSphere® Studio Application Developer (hereafter called Application Developer) and Ant open-source tools.

Application Developer is the IBM development environment for developing e-business applications. Within the Application Developer workbench, you can write, compile, and unit test source code, as well as interact with a software version control system (also known as a software configuration management system or SCM) in order to check in modified files to a central code repository. Application Developer supports the software build process by providing verification, compilation, and assembly tasks that can be extended and customized. Application Developer can also be run in batch, or headless mode, which is precisely what is needed for build automation.

Our build automation process uses the Ant capabilities of Application Developer. The capabilities have been extended by using the antextras package described in the earlier article Using Ant with WebSphere Studio Application Developer. That article explains how to run Ant in headless mode, and provides examples of the code needed to do so. This three-part article series shows you how to use the tools and methodology described in the earlier article to create a fully automated build process.

The remainder of this article (Part 1) explains the overall approach to creating an automated build, including what is required of developers and a description of the tools used by the builder. Part 2 of this series describes how build automation is accomplished using Application Developer V4 with CVS as the code repository. Part 3 describes how build automation is accomplished using Application Developer V5 with IBM Rational® ClearCase as the code repository.

Back to top

Approach

When using the Application Developer environment, you work within a workspace containing various projects, which in turn can contain source code files, compiled object files, and data files such as J2EE deployment descriptor files. Projects also contain metadata files, which contain the information required by Application Developer to compile and package the project executables, including information about the project's library dependencies, build path information, and the manifest of files to be included in packaging the project. Projects are generally self-contained, but may include references or dependencies on objects located in other projects in the workspace, or in objects external to the workspace. You can import a project created in one workspace into another workspace on a different machine, provided that any references to other projects or to external objects are also available to the new workspace. Projects that are successfully imported into new workspaces in this way are guaranteed to build identically to the original project.

Our automated build process takes advantage of the self-contained nature of Application Developer projects to ensure that the build is accurate. Projects that are created, edited, and unit-tested in developers' workspaces are copied to the SCM. The automated build process imports these projects from the SCM into a newly created workspace where they are built, and the resulting artifacts are subsequently exported to the appropriate location. Provided that the build workspace environment has access to all of the external objects required by the imported projects, the build is guaranteed to be accurate.

Here is a brief overview of the approach described in this article series:

1. Developers work on projects in an Application Developer workspace, where they create code, make changes, and unit test. When satisfied with their code, developers copy their projects into the SCM.
2. Builders add the names of any newly created projects to the list of projects to be included in the build.
3. The automation process periodically runs and performs the following tasks within a single, batch-mode (headless) Application Developer Ant session:
1. Extracts all projects to be included in the build from the SCM to a local directory
2. Creates a new Application Developer workspace
3. Imports each project into the new workspace
4. Builds each project in turn
5. Writes any build-time errors to a log output file
6. Exports the executables to an appropriate location. This can be an FTP site or a mounted file system

The above process requires that:

• The SCM contains all source files and all project metadata files (for example, .classpath).
• All dependent external libraries specified in the .classpath are available in the automation workspace.
• All dependent projects are included in the automation workspace.

Developer requirements

First, you must ensure that your projects build successfully within their own workspace when using the Project => Build option in Application Developer.

The automated build process requires that the SCM contain complete copies of projects, including all source files and all project metadata files (for example, .classpath). Project metadata files are often hidden from view according to workspace preferences, which may cause them to be overlooked when copying files or checking them in to the SCM. Developers must therefore make sure that the SCM contains up-to-date copies of their source code and project metadata files.

When creating project references to libraries that are external to the workspace, developers must communicate with builders in order to ensure that these external libraries are also available on the machine performing the automated build. It is always a good idea to use workspace variables rather than hard-coded path strings in these references, so that the location of these libraries need not be identical on the build machine. For example, if a project's CLASSPATH contains a reference to the JAR file dependantJar.jar, which is located at E:\myJars\dependantJar.jar on the developer's machine, the developer should create a workspace variable called ${myJars} which contains the string "E:\myJars". The CLASSPATH reference will then contain ${myJars}\dependantJar.jar, and the build machine may then put dependantJar.jar anywhere that is convenient and set ${myJars} appropriately.

If additional build customization is needed to build a workspace project beyond what is provided by Application Developer, such as batch file execution, it should be incorporated into the Application Developer workspace via the "External Tools" facility.

Automation setup

In order to run the automated build process, the build machine must have Application Developer installed and have read access to the SCM so that it can download the projects to be built. Depending on where the build output files are to be placed, the build machine might also need to mount a network file system or have FTP access to a destination directory.

The remaining setup for the automated build process differs between Application Developer V4 and V5, so the details are described in parts 2 and 3 of this article series respectively.

Back to top

Conclusion

Because of the reliance of the overall software development process on software builds, the benefit of having an accurate, reliable, repeatable, and maintainable build process cannot be overstated. Using Application Developer in conjunction with the techniques described in this article series will help you realize these benefits. Part 2 of this series will show you how to automate builds when CVS is your repository. A sample WebSphere Studio project is included, along with the Ant scripts and wrapper code to run the build from the command line.

About the authors

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Approach
• Conclusion
• About the authors
• Comments

Dig deeper into WebSphere on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers