Context:
A schedule framework has been determined
Forces:
Continuous integration, and developers try to follow a moving target.
Too long between integrations, and developers become blocked from making progress beyond the limits of the last base.
Stability is a good thing.
Progress should be made.
Progress must be perceived.
Solution:
Resulting Context:
The project has targets to shoot for. This affects the Customer view of the process, and has strong ramifications for the Architect as well.
Design Rationale:
See the description of the forces. The pattern owes to Dennis DeBruler at AT&T. The main point of the pattern is that a project should schedule change introduction so the effects of changes can be anticipated. It is less im- portant to publish the content of a change (which will go unheeded under high change volume) than for the development community to understand that change is taking place. It is important not to violate "the rule of least surprise."
It can be helpful to have, simultaneously, various bases at different levels of stability. For example, one AT&T project had a nightly build (which is guaranteed only to have compiled), a weekly integration test build (which is guaranteed to have passed system-wide sanity tests), and a (roughly biweekly) service test build (that is considered stable enough for QA's system test).
Next: Divide and Conquer