• Main Menu
• Home
• Articles
• Books
• Glossary
• Links

How to write a Build Management Plan

1. Introduction

1.1 Scope

The purpose of this article is to define the Build Management procedures to be followed by the HappyBank project – an open source  Java reference application (http://happybank.sourceforge.net).

Note, this article is intended as a working "example" of a Build Management Plan. Although the project it is defined for uses open source rather than commercial build and deployment tools, the template itself can be tailored and applied to any development project. For example, if commercial build and deployment tools were being using in a complex business environment, then there should be more detail included on the integration of build and deployment into the corporate environment and the implementation of build and deployment security.

1.2 Definitions

All definitions are taken from The Buildmeister‘s Guide glossary.

1.3 References

• [SCM] HappyBank Software Configuration Management Plan.
• [BMG] The Buildmeister's Guide, Buildmeister Books.

2. Build Management

2.1 Organization, Responsibilities, and Interfaces

The organizational structure of relevant roles to Build Management are illustrated in the diagram below:

The Build Engineer (Buildmeister) will be responsible for:

• defining the project's build process based on the input of the Developers,
• implementing, automating and securing the build process,
• liaising with the Configuration Manager to ensure that the build process correctly interfaces to the SCM environment,
• automating or initiating the deployment of the application to Development and Acceptance Test environments.

The Deployment Engineer will be responsible for automating or initiating the deployment of the application to Production Environments.

2.2 Tools, Environment, and Infrastructure

The infrastructure that is to be used for supporting the build and deployment process is illustrated below:

The HappyBank build scripts will be version controlled alongside the project source code on the Version Control Server (see the SCM plan for more details). Development Integration builds will be automatically executed on the Build Server and deployed to a local instance of Apache Geronimo for Functional Integration Testing.

The outputs of each successful Integration build will be stored on the Staging Server (in this case a file system share on the Build Server).

Approximately once a week, Feature Drops (Integration builds with specific, testable content) will be deployed by the Build Engineer into the Test Environment for validation by the Acceptance Testing team. Validated builds will then be securely stored back on the Version Control Server as candidate release builds.

The Deployment Engineer will deploy these builds from the Version Control Server into the secure Production Environment as and when required.

The following tools will be used to implement the build and deployment process:

• Apache Ant - for automating the compilation, unit testing and deployment processes.
• CruiseControl - to automate the execution of the Ant build scripts when developer changes are committed to the Version Control Server as well as to initiate deployment of Feature Drops to the Test Environment.
• Apache Geronimo scripting - for automating the provisioning of servers, deployment of release builds and validation of their success on to the Production Environment.

A number of additional, related tools will be used to enforce and assess the quality of the input and output of the build process, including JUnit, PMD and Fitnesse.

3. Build Management Activities

3.1 Build Identification

3.1.1 Build Frequency

Two levels of Integration Build will be carried out as follows:

• Partial Integration Build - conforming to the Continuous Integration pattern and that is carried out automatically on each developer commit. This build will perform full static analysis of the application code base, compile the application and run through a defined subset of critical unit-tests.
• Full Integration Build - conforming to the Daily Build and Smoke Test pattern and that is carried out automatically over night. This build will perform full static analysis, compilation, full unit testing and deployment of the application to the development test instance. A small subset of automated functional tests will be executed on the deployed application for Functional Integration Testing.

3.1.2 Build Identification

The outputs of each build will be labeled with the release number and a unique build number in the form:

filename_REL-BLD.extension.

For example if the release number is 1.1 and the build number is 005, for a Web Application Archive this would result in a file named HappyBank_1.1-005.war. Note, that the Subversion global revision number will be recorded against the build in CruiseControl so that the build can be reconstructed at a later date.

Any Feature Drop builds which have been deployed and successfully validated in the Test Environment will be treated as release builds and the outputs stored in a specific Subversion "release" repository. This repository will also be populated with release specific documentation (see 3.1.3 below).

Build automation projects defined in CruiseControl will conform to the following convention:

• Partial Integration Build projects will be named HappyBank_REL_dev
• Full Integration Build projects will be named HappyBank_REL_int
• Deployment (to Test) projects will be named HappyBank_REL_deploy

where REL is the targeted release number, e.g. 1.1.

3.1.3 Build Directory Structure

The build and deployment directory structure for HappyBank is illustrated below:

Where the contents of this diagram are as follows:

• build.xml – Ant build script(s) for building the application
• default.properties – Ant build properties
• src – Java and HTML source code for the application
• bin – Apache Geronimo deployment scripts for the application
• release_notes.html – description of the changes (new features, defects addressed) in the release of the application
• install.html –- instructions on how to install the application

Note that as the application contains multiple components there will be multiple directories in the src repository with similar structures.

3.1.5 Build Workspaces

The Partial Integration Build will use and update a single Subversion workspace (working directory).

To ensure a clean and repeatable build process, the Full Integration Build will create and populate a new Subversion workspace.

A file system directory will be created on the Build Server to hold CruiseControl build results and build outputs.

3.2 Build Control

3.2.1 Security and Authorization

The following security restrictions will be implemented on the project:

• Any user will have permission to update the Apache Ant build scripts and CruiseControl projects, however because of availability and experience it is expected that the Build Engineer will carry out these changes.
• The Build Engineer role will be the only role authorized to deploy to the Test Environment.
• The Build Engineer role is the only role authorized to commit a validated release candidate build to the Version Control Server.
• The Build Engineer role is the only role authorized to update and version the release documentation.
• The Deployment Engineer role will be the only role authorized to provision and deploy to the Production Environment.

Where authorization is required this will be enabled by standard user login and password mechanisms. Usernames and passwords will be permitted to be cached for deployment to the Test Environment but not for deployment to the Production Environment.

3.2.2 Integration to Configuration and Change Control

See the SCM plan for more details on how the build and deployment process is integrated to Change Control.

4 Build Status Accounting

4.1 Project Media Storage

All Integrations builds are transient are not expected to be backed up. All candidate release builds will be backed up with the Subversion repository - see the SCM plan for more details.

4.2 Release Process

The release process for HappyBank is illustrated in the diagram below:

In more detail these steps are as follows:

4.3 Reports and Audits

An overview of activities for monitoring and reporting on the build process are provided below:

4.4 Milestones

Milestones are described in the project's Microsoft Project Plan.

5. Training and Resources

The following training courses are recommended by role.

6. Subcontractor and Vendor Software Control

HappyBankdoes not currently subcontract software development. However, they do incorporate open-source products into their systems which must be carefully controlled. The versions of all of these products and tools used in the Development, Acceptance Test and Production Environment‘s (including Apache Ant, CruiseControl and so on) are recorded in the SCM plan.

Appendix A - Administration Procedures

Issues to be covered include:

• How to reuse Ant common targets when a new project component is developed.
• Support and maintenance of Apache Geronimo application server environments.
• Archiving and maintenance of CruiseControl projects and build results.

The backup and recovery of Subversion repositories is detailed in the SCM plan.

Comments

There are no comments on this article.

Back to Top

Submit a new comment

All fields in bold are required.

Name:

Website:

Comment:

Reload Image

Catchpa:

   Processing...