Create a new page
Create a to-do list
Plan a trip
Store photos
See all templates

DRAFT DRAFT -- WORK IN PROGRESS

This paper is not being actively developed, However slides and an example can be found from the links in my blog

A paper on how to manage built artifacts in and out of Subversion (SVN)

Early copies of the a working make and driver script have been added to this WiKi for people who want to experiment

Introduction

This paper shows how the Configuration management change loop can be completed by managing the build process from the Version Control system, in this example Subversion and GNU Make.

A process will be presented that:

Ensures that all inputs to the build process are identified using a tag
Identifies all builds with the build environment in which the build took place
Places the build outputs under configuration management

In addition possible areas of future development will be discussed, including the re-use of already built artifacts to speed up build time.

What is Software Building

When building software we take some input files, usually source code but they could be anything, and create some output files. Note that this paper does not discuss building code that is installed in some external environment such as a database.

In many organisations the build process is given far too little attention. Common mistakes include

Not knowing what version of the code was used to build a specific output file
Not knowing what software tools and third party libraries where used to build software

Developers frequently supply production binaries created on their desktop PC's

Not recording the results of the build for historical traceability. This includes information such as:

The specific options that where chosen for each tool used in the build
The software versions used in the build process

In my many years of advising customers on their software process I am constantly disappointed by how many fail to see the value of an adequate build process or are not prepared to apply the effort to implement and maintain one. The sad fact is that failure to address the build process can break the entire SDLC and result in huge costs as people run around trying to answer the question "what's different in production that made it break today?".

With the use of automated testing tools and frameworks the value of a automated build process is increased even more.

There are other sources that talk about the mechanics of the build environment and creation of build scripts. I would like to talk about the interface between the build system and the configuration management system.

For the purposes of this discussion there are three distinct build processes

Sandbox builds that occur in a developer sandbox. The products of this build of not used outside the sandbox and are of no CM interest, other than they should not pollute the system build products

Integration Builds or Smoke Tests -- to ensure that the software builds. It should be noted that unit tests are often invoked as part of this process

System builds. These builds are performed by automated processes and create builds for two purposes

Creating deployment artifacts -- Creates outputs that is deployed to environments for some level of testing or for production release.

Providing a record of the build process for production audit purposes (NB Many current build systems fail in this requirement)

The importance of the Build Record

From a configuration management perspective two of the key requirements are Accounting and Audit. These are not just academic concerns. We must be able to:

List all the artifacts and versions that compose a specific version of our product
Show which changes have been made to product version and that the work was carried our correctly.

A full discussion of this is ouside the scope of this paper, however it is important that the build process does not break the audit trail of information between our released product and the changes that were developed in our various environments.

In certain circumstances there may be legal ramifications if we are unable to supply this information.

System Builds

Ideally all system builds will be done in separate build environment distinct from the various runtime environments. This build environment should be subject to CM Change Control, e.g. a Lightweight Ticket Process.

A system build must be done against a tagged version of the input files (a baseline).

When the build is complete then consider placing the outputs from the build process under CM control. In subversion this can be done as follows:

Copy the input files onto a new 'build' branch. Consider having a 'builds' top level directory in your repository
Copy the source branch to the build branch -- this is our input baseline
The build environment should used a predefined CONFIG_ID (set in an environment variable). This should relate to a change ticket
Generate a BUILD ID -- It consists of the CONFIG_ID concatenated with the date YYYYMMDDHHMMSS
As part of building each output perform an svn add <outputfile> , on the build branch # TODO -- test this
At the end of the build perform a svn ci. This will add the new files built
Apply two custom properties to each build file in Subversion a)The CONFIG_ID and b) the BUILD_ID
Close the build log
Add and check in the build log to subversion on the Build branch and add the BUILD_ID property