Continuous Staging: Scaling Continuous Integration to Multiple Component Teams

and signed" deliverables only for that one specific component!

Using a Staging Area

A common best practice used to coordinate cross-component build dependencies is commonly called a " Staging Area" or " Staging Environment". A Staging Environment is like a "sandbox" or "workspace" reserved for sharing build/test dependent artifacts (headers, libraries, executables, etc.). It works something like this (note, this is not specific to XP/Agile development):

• Each subteam "does its thing" and builds and compiles its code as they should and commits changes to their repository in the usual fashion

• At agreed-upon points in time, the subteam "delivers" any artifacts that other teams require in order to build (headers, APIs, libraries, configurations, etc.) into the staging area (and ideally some additional level of build/test is done)

Figure 1. Delivering Built Components into a Staging Area

• When building in one's private developer workspace or even a subteam's integration workspace/machine, the compilers and linkers (etc.) point to the "official" staging area for the non-subteam owned artifacts needed for the subteam to build their component.

Staging AreaIf versioning is required, then it is typically handled one of two ways: Staging AreaStagingRepositoryStaging Area

Staging Area Implementations and Versions

The issue of versioning comes into play if it is necessary to know which version of a component is the "current" one in the staging area. If necessary, then:

• When a subteam build has its executables delivered to the staging area, it also creates a corresponding tag/label, and perhaps writes it to a file (e.g., README or whatever) for that component in the staging area (a simplified form of "version description document" or VDD).

Staging Directory : a separate directory tree in the repository is used to house any "installed" staging artifacts (staged artifacts). Developers will typically use the staging area plus the top-level directory for their own components in their sandbox (and don't extract/checkout anything else unless and until they need to view the source for something outside their owned component).

Figure 2. Staging Directory Versioned in same Repository as Components

Staging Repository : a separate repository is used to house all staged artifacts. It can therefore accommodate separate sets of versions and tags/labels (which has good points and bad points)

Figure 3. Staging Repository and Separate Component Repositories

Sometimes granularity of access-control, administration, mirroring/synchronizing will determine which of the above two approaches is best. If each component is large enough to already warrant its own separate repository from the others, then a separate staging repository is typically used.

Sometimes, for local performance, a staging area might be mirrored or replicated to local sites/storage to cut-down on network bandwidth for their build-cycle time.

Making it "Agile"

The Staging Area is a specific technique for separating (sub)team build-dependency interface from implementation for the benefit of the rest of the team(s). A Staging Environment is the component-version "mediator" (coordinator really) that houses the common interface and necessary artifacts to satisfy build/test dependencies across subteams.

How might we apply an "agile" adaptation of it? Well, the "simple" case is when no separate staging area is needed because the whole "one team" can peacefully co-exist in "one repository" and each work at their own "sustainable pace" without unduly impacting the others. So there is little need to think so much about subparts and subteams and instead more easily focus on "the whole"

Other times, factors of scale rear their ugly head! These may be issues of system/build scale, organization and organizational process, issues of ownership over computing resources, etc. (or maybe not all the subteams are using "agile" and some of them can't tolerate such high-frequency