Skip to content

Build Automation Tools

August 12, 2009
tags:
Build automation is the act of scripting or automating the process of compiling computer source code into binary code. This automated build is in contrast to a manual build process where a person has to perform multiple, often tedious and error prone tasks. It involves automating a wide variety of tasks that a software developer will do in their day-to-day activities including things like packaging binary code, running tests and deployment to production systems. The goal of this automation is to create a one-step process for turning source code into a working system. This is done to save time and to reduce errors.
Types of automation:
1. Commanded automation such as a user running a script on the command line
2. Scheduled automation such as a continuous integration server running a nightly build
3. Triggered automation such as a continuous integration server running a build on every commit to a version control system.
Best practices:
– Keep the build file at the root of the project
– Use consistent style and conventions
– Don’t Repeat Yourself (DRY)
– Provide good help
– Manage dependencies properly
– Use per-user properties to allow people to override defaults such as database
logins or directory locations
– Keep the build self-contained
– Keep it all in source control
Build automation is the act of scripting or automating the process of compiling computer source code into binary code. Below is a list of notable tools associated, at least in part, of the build automation process.
Make-based tools:
1. Make             – a classical Unix build tool
2. dmake           – used in the build process for some Sun Microsystems software,
including OpenOffice.org and Solaris
3. Makepp         – A build tool written in Perl, almost completely compatible with the
original make
4. Mk                – developed originally for Version 10 Unix and Plan 9, and ported to
Unix as part of plan9port
5. Module          – Build, a Perl module for the building and installation of other Perl
modules, improving upon the existing ExtUtils::MakeMaker module,
which actually uses make to do the building .
6. nmake           – Bell Labs’ nmake, forked into two versions after the AT&T rivestiture:
a research version from AT&T Labs and a supported Alcatel-Lucent
Bell Labs version.
7. Speedy Make – XML based make utility with emphasis on ease of use.
8. Openmake     – a commercial enterprise build management tool.
8. Rake             – a Ruby-based build tool.
9. MPW Make     – Developed for Mac OS Classic and similar to but not compatible with
Unix make. Mac OS X comes with both GNU make and BSD make.
Other tools:
Apache Ant                – popular for Java development and uses an XML file format
Apache Maven    – a Java tool for project management and automated software
build
CABIE                – Continuous Automated Build and Integration Environment,
Open Source, written in Perl BuildIT, a free graphical build or
task tool for Windows with an emphasis on simplicity and ease
of use
CMake               – a tool that generates files for the native build environment,
such as makefiles for Unix or Workspace files for Visual Studio.
Cook                 – a build tool with a C-like syntax
FinalBuilder       – GNU Build Tools, a collection of tools for portable builds
MSBuild            – The Microsoft Build Engine.
NAnt                 – A tool similar to Ant for the .NET framework
OMake              – An open source build tool with a custom scripting language
built on top of Make-like syntax, integrating functionality
similar to autoconf/automake
Want                – an Ant-like XML-based tool for building programs, written in
Delphi
Example:
xUnit
Various code-driven testing frameworks have come to be known collectively as xUnit. Such frameworks are based on a design by Kent Beck, originally implemented for Smalltalk as SUnit, but are now available for many programming languages and development platforms.
xUnit Design:
The overall design of xUnit frameworks depends on several components.
1. Test Fixtures
A test fixture is the set of preconditions or state needed for a test to run. Also known as a test context.
2. Test Suites
A test suite is a set of tests that all share the same fixture.
3. Test Execution
The execution of an individual unit test proceeds as follows:
setup();
/* Body of test */
teardown();
The setup() and teardown() methods serve to initialize and clean up test fixtures.
Assertions
An assertion is a function or macro that verifies the behavior of the unit under test. Failure of an assertion typically throws an exception, aborting the execution of the current test.
Apache Ant is a software tool for automating software build processes. It is similar to make but is written in the Java language, requires the Java platform, and is best suited to building Java projects.
The immediate difference between Ant and make is that Ant uses XML to describe the build process and its dependencies, where as make has its Makefile format. By default the XML file is named build.xml.
Ant is an Apache project. It is open source software, and is released under the Apache Software License.
Ant was conceived by James Duncan Davidson while turning a product from Sun into open source. That product, Sun’s reference JSP/Servlet engine, later became Apache Tomcat. A proprietary version of make was used to build it on the Solaris Operating Environment, but in the open source world there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform-independent tool to build Tomcat from directives in an XML “build file”. From this humble beginning, the tool has gone on to become more widespread – and perhaps more successful – than the Tomcat product for which it was created. Ant (version 1.1) was officially released as a stand-alone product on July 19, 2000. It has become the underpinning of open source Java; developers expect a “build.xml” file with every project.
Because Ant made it trivial to integrate JUnit tests with the build process, Ant has made it easy for willing developers to adopt test-driven development, and even Extreme Programming.
Sample build.xml file
Below is listed a sample build.xml file for a simple Java “Hello, world” application. It defines four targets – clean, clobber, compile and jar, each of which has an associated description. The jar target lists the compile target as a dependency. This tells Ant that before it can start the jar target it must first complete the compile target.
<?xml version=”1.0″?>
<project name=”Hello” default=”compile”>
<target name=”clean” description=”remove intermediate files”>
<delete dir=”classes”/>
</target>
<target name=”clobber” depends=”clean” description=”remove all artifact files”>
<delete file=”hello.jar”/>
</target>
<target name=”compile”
description=”compile the Java source code to class files”>
<mkdir dir=”classes”/>
<javac srcdir=”.” destdir=”classes”/>
</target>
<target name=”jar” depends=”compile”
description=”create a Jar file for the application”>
<jar destfile=”hello.jar”>
<fileset dir=”classes” includes=”**/*.class”/>
<manifest>
<attribute name=”Main-Class” value=”HelloProgram”/>
</manifest>
</jar>
</target>
</project>
Within each target are the actions that Ant must take to build that target; these are performed using built-in tasks. For example, to build the compile target Ant must first create a directory called classes (Ant will only do so if it does not already exist) and then invoke the Java compiler. Therefore, the tasks used are mkdir and javac. These perform a similar task to the command-line utilities of the same name.
Another task used in this example is named jar:
<jar destfile=”hello.jar”>
This ant task has the same name as the common java command-line utility, JAR, but is really a call to the ant program’s built in jar/zip file support. This detail is not relevant to most end users, who just get the JAR they wanted, with the files they asked for.
Many Ant tasks delegate their work to external programs, either native or Java. They use Ant’s own <exec> and <java> tasks to set up the command lines, and handle all the details of mapping from information in the build file to the program’s arguments -and interpreting the return value. Users can see which tasks do this (e.g <cvs>, <signjar>, <chmod>, <rpm>), by trying to execute the task on a system without the underlying program on the path, or without a full Java Development Kit (JDK) installed.
Portability
One of the primary aims of Ant was to solve make’s portability problems. In a Makefile the actions required to create a target are specified as shell commands which are specific to the current platform, usually a Unix shell. Ant solves this problem by providing a large amount of built-in functionality which it can then guarantee will behave (nearly) identically on all platforms.
For example, in the sample build.xml file above the clean target deletes the classes directory and everything in it. In a Makefile this would typically be done with the command:
rm -rf classes/
rm is a Unix specific command which will probably not be available if the Makefile is used in a non-Unix environment such as Microsoft Windows. In an Ant build file the same thing would be accomplished using a built in command:
<delete dir=”classes”/>
A common discrepancy between different platforms is the way in which directory paths are specified. Unix uses a forward slash (/) to delimit the components of a path, whereas Windows uses a backslash (\). Ant build files let authors choose their favorite convention, forward slashes or back slashes for directories, semicolon or colon for path separators. It converts everything to the appropriate format for the current platform.
Limitations
Ant build files are written in XML. For unfamiliar users, both XML itself and the complex structure of Ant documents can be a barrier to learning. Moreover, the language Ant uses is quite verbose and the build files of large or complex projects become unmanageably large; good design and modularization of build files can improve readability but not reduce size. Other build tools like Maven use more concise scripts at the expense of generality and flexibility.
Many of the older tasks¬タヤthe core ones that are used every day, such as <javac>, <exec> and <java>¬タヤuse default values for options that are not consistent with more recent tasks.
Reuse of build file fragment is hard. Ant1.7 makes it easier, with <import> and <macrodef>, but this does run the risk of providing even more complexity for new Ant users to get into trouble with.
Advertisements
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: