You cannot implement a Software Build and Release Management process using only a single tool. A combination of related and integrated tools is required. Unfortunately, quite a few tools can fit into the Software Build and Release Management category. Try carrying out a simple Internet search for "software build and release management tools," and a bewildering and vast array of results is returned. To simplify the implementation, I will use a small subset of the available tools and configure them to help you support your needs. These tools have been chosen based on common usage patterns. They tend to be the tools that are the most widely used and are also the most integrated.
Table 2.1 shows the suite of tools we will be using. They are listed next to the build or release phase they help implement and automate (there is some overlap).
You need to know very little about these tools to benefit from this book. I will introduce each of the tools, and then I will describe in more detail how they are installed, configured, and customized to automate the process in the following chapters. The only exception is with IBM Rational ClearCase and ClearQuest. Because these tools are usually part of an enterprise infrastructure installation, I assume that they are already available for use. If not, refer to the ClearCase product manuals [ClearCase03]; Wahli, Brown, Teinonen, and Trulsson [Wahli04]; or Bellagio and Milligan [Bellagio05] to understand more about the installation and initial configuration process.
IBM Rational ClearCase
The most fundamental and important tools we will be using are the Software Configuration Management tools. As I stated in Chapter 1, "Introduction to Software Build and Release Management," a successful Software Configuration Management environment is the foundation for being able to implement an integrated and automated software build and release process. From Table 2.1, you can also see that the use of IBM Rational ClearCase is pervasive throughout the book.
Because the use of ClearCase is so fundamental, I will take time to revisit some of its concepts and capabilities later in this chapter. It is important to understand these concepts and capabilities, because I will be making use of them in our automation efforts. ClearCase supports all the requirements for implementing the Software Configuration Management tool that we identified in Chapter 1. Furthermore, ClearCase is scaleable for any size of project, from small colocated development teams to large distributed multisite projects. You should have no fear that you will outgrow ClearCase.
IBM Rational ClearQuest
IBM Rational ClearQuest tracks and manages any type of change: enhancement requests, change requests, defectspotentially any changes you need to keep track of during the software development life cycle. It gives you the freedom to define and deploy your own change request and defect tracking process. In ClearQuest you define entity types to model the changes in your environment. An entity type is a metadata object that describes the structure of a type of record, including its fields, states, actions, and forms. For example, when defining a defect entity type, you include fields such as headline, severity, description, and owner. You also define a life cycle for the defect similar to that shown in Figure 2.1.
Figure 2.1. ClearQuest defect entity typestates and actions
In Figure 2.1, a change is submitted before being assigned to the relevant person. This person then opens and reviews the change before sending it to another user to be validated. This is a very basic but typical work flow for something like a defect. However, the point is that ClearQuest allows you to define whatever work flow, roles, responsibilities, and permissions you require.
ClearQuest is of most use during the software release management phase, because it can be used to ascertain the contents of your builds and releases at a functional level. For example, when you create a build, you can use ClearQuest to tell the testing team exactly what functionality is present in the build and what defects have been addressed. You can also use ClearQuest to model the deployment process, defining the roles, responsibilities, and work flow of how your software will eventually be made available to your customers. I use ClearQuest in detail in Chapters 9, 10, and 11.
Apache Ant is a Java-based build tool. It has been around for several years and now is the de facto standard for compiling source code and creating distributions on Java projects. Ant is written in Java and is extensible, allowing the user to build on its features and facilities to integrate it with all manner of tools and systems. Since Ant was designed primarily for building Java applications, it consequently understands the Java domain and how to use it. As a Java application, Ant is also cross-platform, meaning that the build files you create on one platform run without conversion on any other supported Java platform. In comparison, commands in makefiles are often written as nonportable shell commands.
Ant uses the concept of a central build file. It is usually called build.xml, and it is usually located at the top level of your project directory structure. This file contains the steps (or targets) describing how your project should be built, such as what source files need to be compiled, what unit tests are to be run, and how to package all the files for distribution. Executing an Ant build therefore is a simple matter of invoking Ant from the command line and specifying which target you want to run.
Apache Ant is an open-source tool maintained by the Apache Software Foundation. Its home page is http://ant.apache.org. Ant's installation and configuration are described in Chapter 4, "Defining Your Build and Release Scripts."
CruiseControl is a framework for a continuous build process that allows you to automate the execution of your builds and report on their results. CruiseControl was written to realize the process of continuous integrationan agile development practice for frequently integrating small changes into a project. However, CruiseControl does not dictate this process. You can use it for any project where integration builds are carried out frequently (usually at least once a day or once a week). CruiseControl wraps around your existing build scripts that have been defined using Apache Ant.
You can configure CruiseControl to schedule build execution as frequently as you want, but you usually specify that a build should be carried out only if something has changedwhich makes sense! To achieve this, CruiseControl includes the concept of a "modification set"the changes on a project integration branch or the files committed to a repository. If files have been modified, the build is executed. CruiseControl can automatically generate e-mails when something goes wrong, as shown in Figure 2.2.
Figure 2.2. CruiseControl e-mail notification
CruiseControl also makes available a central build results Web site for reviewing the results and statistics of current and historical builds. On this Web site you can see the details of all the builds carried out, what has changed in each build, a description of any errors, test results, and some basic build metrics.
CruiseControl is an open-source tool maintained by ThoughtWorks. Its home page is http://cruisecontrol.sourceforge.net. The installation and configuration of CruiseControl are discussed in detail in Chapter 6, "Running Your Build Scripts."
As its name describes, JUnit is a unit testing framework for Java. It is included as one of our tools because running a suite of JUnit tests during a build can increase your confidence that the build carried out will actually work. With JUnit, you write code to test your code, instantiating and performing operations and assertions on your Java classes. For example, suppose you were creating a new Java class to model a customer's bank account, and the account will hold data and have methods to access the data as follows:
// private data private String id; // account identifier private String type; // account type private BigDecimal balance; // account balance // public methods public Account() public Account(String accountid) public String getId() public String getType() public BigDecimal getBalance() public void setId(String id) public void setType(String type) public void setBalance(BigDecimal balance) public BigDecimal deposit(BigDecimal amount public BigDecimal withdraw(BigDecimal amount)
Before you even wrote the Java code for this class, it would be good practice to work out how to exercise it, identifying what would be the successful, boundary, and error conditions. For example:
The expected outcomes of these decisions can be coded with JUnit using what it calls assertions. You would therefore write a test class to instantiate the account class and exercise its methods. At certain points in the code you assert what should happen, based on the input you provide. For example, if you tried to request information on an account that did not exist, you would assert that an exception should be raised. When executed, the JUnit test case would fail, and you would know that you had a problem with the code for your account class.
This is a very basic unit test; however, the principle is the same for any piece of Java code. This method of planning and writing the tests first is called test-driven development, and it can be stated as follows for new functionality:
In practice, the combination of test-driven development and continuous integration can be a very powerful and effective way of incrementally delivering software in dynamic environments. Other tools in the nUnit family can execute different types of tests using the same framework as JUnit. For example, HTTPUnit can execute functional tests on a set of Web pages using the HTTP protocol, and SQLUnit can execute tests on database stored procedures.
JUnit is an open-source product maintained by the open-source community. Its home page is www.junit.org. When developing any new code in this book, I also adopt the practice of test-driven development and illustrate how to create basic JUnit test cases. However, for more background information and details on how to construct JUnit tests and test suites, see Hunt [Hunt03].
For the purposes of automating specific tasks in Software Build and Release Management, there is often a need to write scripts. For example, you might need to extract software deliveries into specific directory structures, wrap processes around version control tools, or extract text patterns to create release notes. Many scripting languages are available on different platforms, but Perl (Practical Extraction and Reporting Language) is one of the most widely used. It is relatively straightforward to learn and great for creating basic but functional scripts. However, when needed, Perl also has the power and capabilities of a full-blown procedural or object-oriented language.
Like Java, Perl scripts are quite portable, and with a little care, they can be created to be executed on multiple platforms. Perl is an open-source tool maintained by the Perl foundation. Its home page is www.perl.org. Perl is a common tool for creating custom scripts, extracting information, and enforcing processes with both ClearCase and ClearQuest. Therefore, Perl version 5.8.6 comes preintegrated with the latest versions of them. I describe how to use this integrated version of Perl in more detail in Chapter 8, "Baseline and Change Request Reports." To understand more about Perl's syntax and capabilities, read through the wealth of information on www.perl.com/, or refer to the book I first learned Perl from, Learning Perl [Schwartz05].
OK, I admit it. XML (eXtensible Markup Language) is obviously a markup language, not strictly a tool. However, XML is well suited to managing, displaying, and organizing data. Because such data manipulation and presentation are a large part of the Software Build and Release Management process, it is not surprising that we will be using this technology. Most of the build tools discussed in this chapter (Ant, CruiseControl, JUnit) use XML files as their input or output. You can also transform any XML formatted file into an HTML Web page using XSL/XSLT (XML Stylesheet Language/Transformations) technology. Using XML is therefore a great way of producing generic output, such as for release reports and then applying the transformations to present the information in any way you want. I use XML as an output format in Chapters 8 and 9. It is therefore worth spending some time understanding the basic concepts of XML. I recommend the first few chapters of Hunter, Watt, Rafter, Cagle, Duckett, and Patterson [Hunter04] as a good introduction.
Other Build Tools
You can use a number of other build tools to complement or replace those we have identified. In particular, a number of commercial build execution and reporting tools could be used instead of CruiseControl. Examples include BuildForge, AntHill, ParaBuild, and OpenMake. Each of these tools has its own merits (see the following sidebar). They typically include additional features above and beyond CruiseControl, such as security, build distribution, and impact analysis. For large development organizations, these tools are certainly better at managing and reporting build progress and results across many projects, potentially on different platforms and developed using different languages. However, since CruiseControl is open-source, no licensing costs are involved, and there is an active user community to share knowledge with. Consequently, I recommend that you try CruiseControl first to see if it meets your needs before looking at other commercial tools.
What About My IDE?
You might have noticed that I have not included an Integrated Development Environment (IDE) in our toolset. This is quite deliberate! There are many Java IDEs, although Eclipse (www.eclipse.org/) and its commercial equivalents are probably the most prevalent. However, it is difficult to guarantee that a build initiated in one developer's IDE is initiated in exactly the same way (and with the same environment) with other developers. Further, when constructing an Integration Build, you should do this on a scheduled or modification basis using CruiseControl. In this case your build scripts should therefore be able to be executed externally from the IDE. With the prevalence of Ant, however, the good news is that most IDEs now support the direct editing and execution of standard Ant build scripts. I discuss the capabilities for this in Eclipse in Chapter 4.