There are two standard promotion models:

1. Promote source code and rebuild at each promotion stage, and
2. Promote builds and tie their promotion to a "snapshot" or "baseline" of the source used in its construction.

We use this second model.

During a build, two types of binaries are created and another is consumed. These are:

• Deliverable binaries, also called Artifacts by AnthillPro
• Intermediary binaries that would be of some use if we used incremental builds, but do not buy us anything at this time
• Binary files that are effectively source that are included in the Deliverables

Deliverable Binaries -- These are initially preserved in AnthillPro as Artifacts as well as externally in a CM controlled staging area available in read-only mode to both Development and Quality Control (QC). Since we do thousands of builds per year, keeping all of these potential release candidates (especially when we know they were never released) would present an unacceptable storage problem.

This means that when QC selects a build for functional testing, they do so from either the artifacts or the external staging area, depending on their needs at the time. They have a finite time to do so before they exceed an age or quantity limit at which point the deliverables (artifacts) are automatically removed from the system.

As a part of the Release Management system, QC has the ability to perform a release of a build as either an Internal Test Candidate (ITC) or a formal Release Candidate (RC). ITS releases are primarily used by QC to perform functional tests, while RC releases are used for final regression tests. In either case, a target release "name" is specified. Selection as either type of release prevents the build from being purged unless a subsequent release (either ITC or RC) is performed. If that happens, and it does all too frequently, the Artifacts and any associated archives are replaced by the subsequent release and and the original build allowed to once again be purged by the system.

The primary difference between ITC and RC releases is that RC releases perform additional archival steps. All associated Artifacts are replicated to CM controlled archival storage and from there backed up by the IT department to tape for both local and off-site long term storage It can get complicated to describe, but what is really happening at this point is that the deliverables are being moved around and tagged with the appropriate release identification information. Everything else is more of an electronic signature and approval process.

Once Quality Management actually approves an RC release, it is released to one or more CM controlled external staging areas and a status in AnthillPro is set to Preserved to flag the original build so that neither its Artifacts nor its associated metadata (logs, reports, metrics, build records, etc.) will ever be purged from the build system. Beyond that, it is up to the end-user to elect to install or upgrade from the appropriate staging area.

Of course, all successful builds trigger a snapshot in AccuRev, so it is easy to trace back from the Release all the way to the source that was used in its construction.

Intermediate Binaries - These are discarded after each build. If we were interested in build optimization for developers we would keep these around so that dependency style conditional (incremental) builds would be possible, but since each of our builds is a potential Release Candidate, we do clean builds from controlled source (maintained in AccuRev) all of the time.

Consumed Binaries - For Product builds, we treat these just like source code and keep them in AccuRev. AnthillPro has a mode of operation called CodeStation that allows the storage, control and versioning of large binaries that change at reasonably infrequent intervals and that in turn can be selected as a part of each build's properties. We plan to use this capability when we start building DVD ISOs for field installation (where some of the binaries will include a specific Product Release, a database management system (embedded), specialized drivers, tool installation packages, etc.), but we do not use it for our current Product builds

Note that we did evaluate using CodeStation to control the use of FOSS Third Party components in Product builds. CodeStation and AnthillPro worked well, but it was a problem for developers doing local builds under Eclipse on their workstations. Due to our development paradigm, it was decided that this was not a good solution for us, even though it gave CM greater control over the use of external components. Other organizations that do not allow their Agile Developers to change these components at will, might well have better luck using CodeStation for FOSS component control in their builds.

References
AccuRev - http://www.accurev.com/
AnthillPro - http://www.anthillpro.com/html/default.html

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment