Continuous Staging: Scaling Continuous Integration to Multiple Component Teams

of changes/deliveries from the agile-teams into their own part of the repository.

One of the key problems to solve is when and how-often a subteam should do a "signed and sealed" delivery into the staging area. If every commit to the codeline is too frequent for a staging delivery, then an arrangement must be negotiated with the other subteams. This is where some agile methods try to "scale" by using a team of teams (e.g. a "Scrum of Scrums") to manage the staging frequency and coordination.

Scaling Continuous Integration up to Continuous Staging

If it is necessary to "scale-up" my build process & resources to use a Staging Environment, how might I "scale-up" a practice like "Continuous Integration" to approximate " Continuous Staging " into the staging area? This would avoid, or at least minimize the need to tag/label every delivery into the staging area, and hence minimize the need to manage build-version-dependencies between components and the subteams that work on them. Even if it were no longer practical to use a single repository or full system build for every commit across the whole team, it might be feasible to:

• Have every commit (or even just once or twice daily) "trigger" a delivery to the staging area.

• Another trigger (or perhaps the same one) detects an update to the staging area and does the next-level of build/link/test (automated of course) using the current set of items in the staging area.

• If it breaks, you take the appropriate course of action and notifications (just as one does for Continuous Integration at the smaller scale)

Even in those cases where you might still need to "version" the repository (and component) for what you delivered to the staging area, the staging area itself can be used to manage the current latest and greatest set of "system buildworthy" components and their versions (both source and binaries).

Component Versioning and Releasing

If the development of all your components results one coordinated release of a single application or system, then it maybe best to version the source files, not the compiled libraries. Even when "versions" are associated with what gets delivered to the staging area, they typically refer to versions of the source that produced the "staged" deliverables.

If however your result is really an overall product-family or product-line of multiple components that feed into multiple products for multiple deliverable systems, then the component/library reuse and independent component release schedules may make it necessary to version the binary/library releases.

In the latter case of a product-family, each component release is essentially a release of a third-party component to each of the other component teams. The vendor release in this case originates from elsewhere within the organization (rather than an external supplier), but the underlying business model for reuse and release of components matches that of third-party vendor/supplier (albeit an internal one).

There are truly external vendor and third-party deliverables, and then there are items that may be internal to your organization, but should be regarded as internally vendor/3rd-party supplied to your particular product and team. And in those cases versioning the delivered binaries is recommended.

Some shops use a separate Third Party Repository for such purposes. One of the reasons is because its supplier and release schedule is independent of the rest of the application. Another reason is that if most of the elements are binary in nature, it is often desirable to have a distinct storage area with more efficient storage parameters/capacity (and sometimes the repository can be configured so it is "tuned" for performance based on knowledge of the kinds of elements