noticed that we have grouped together what some would consider two different kinds of release builds  under the same heading: QA Release Build and Customer Release Build. They were lumped together because they both represent a scope of stakeholder visibility outside of the development team, and any build that will be visible outside of the development team needs to satisfy some more formal criteria and additional needs beyond that of development.
At the same time, the difference between QA build and release build is an important one that underscores some of the critical organizational issues that are not addressed by some of the more popular “Agile” methodologies like Scrum and Extreme Programming.
The emphasis on smaller teams, shorter feedback cycles and close customer collaboration can make us forget that it is often not feasible to remove all the additional layers of stakeholders between the team and the end-customer. In an ideal world for example, the customer would receive every build that made it past QA, or at least the result of every iteration. In reality, the customer won’t always agree to tolerate such frequent delivery and may agree only to take the end-release, or the result of every third or fourth iteration. Because of this, there is often an entire layer of organizational infrastructure and stakeholder communication sitting in between the team and the end-customer. Even if this extra layer is not ideal, it is often reality.
Build Status Accounting
With all these different kinds of builds, and knowing how important software builds are, it stands to reason that knowing the status of code that is ready-to-build or already-built is similarly significant. Accounting for the status of “built” or “to be built” code is a subset of configuration status accounting (one of the four key disciplines of CM, as defined by IEEE and Mil standards).
Build status accounting is often accomplished using a technique called promotion lifecycle modeling. Promotion lifecycle modeling (or “promotion modeling”) involves defining the important milestones when CM artifacts transition to a new level of control and/or ownership. A promotion lifecycle is a specific instance of a promotion model that identifies the lifecycle of promotion levels for a particular project and its development lifecycle. For some reason (perhaps historical), when talking about the status of CM activities like projects, requests, and change-tasks, we tend to talk about states. When talking about the status of CM artifacts and work-products, though, the term promotion level is often used instead of the more familiar “state”.
When defining and using promotion levels (or, for that matter, lifecycles and state transitions) it is always important to ask the questions “of what?” and “for what?” This forces us to clarify both the content and the context of a promotion lifecycle and select and appropriate implementation:
- Content: What is being promoted? Is it a set of files or file-versions (e.g., a change-set)? Is it a build? Is it a branch (codeline)? Is it a label (or “tag”)?
- Context: Why is it being promoted? What “thing” is it a lifecycle “of”? Is it for a particular project or release? Is it for a particular market or platform variant within a release? Is it for development at a particular site for a given release and/or variant?
In an agile context, the important milestones in a build promotion lifecycle are likely to correspond very closely to each of the different kinds of builds and their audiences as described in the previous section.
Build Promotion “Patterns”
Once we have discovered and defined an appropriate promotion lifecycle for our project, the next question will be how to implement it using