Agile Build Promotion: Navigating the Ocean of Promotion Notions

[article]
Summary:
In this article Brad Appleton delves into the realm of build status accounting to discuss various build promotion models and how to choose an appropriate and effective implementation of a build promotion lifecycle.

In keeping with this month’s theme of build and deploy, it seems appropriate to revisit our earlier article on Agile Build Management [1] and reflect a bit further on the ramifications for software builds, packaging, release, and deployment. We will use this as springboard into the realm of build status accounting to discuss various build promotion models and how to choose an appropriate and effective implementation of a build promotion lifecycle. 

Why Are Builds So Important?
The build is where the rubber meets the road or, more accurately, where the customer meets the code. The code has several customers:

  • Other developers who must modify/debug, integrate, build and test the code
  • SCM and QA/test who must formally build and test the code
  • Customers and end-users who must evaluate, operate, administer and upgrade the system

The build is the first opportunity for holistic feedback of system.  What was previously broken apart into individual changes and modules is now an integrated executable whole. By the same token, the build is also the first post-development opportunity for systemic bottlenecks and show-stoppers to significantly slow down, or even halt, the progress of the whole team. We could go on, but we probably don’t need to spend much time explaining to SCM-folk about how important the build is to the success of the project; most of us already know all too well from more times than we can count.



Agilists and the Three Builds (With Apologies to Goldilocks)
In the story of “Goldilocks and the Three Bears”, the character of Goldilocks tests the functionality of three different items, sampling each one three different ways until it is just right before going on to the next one.  Who would have guessed that Goldilocks was a member of QA?  In our previous article on Agile Build Management [1], we talked about Agility and “The Three Builds”, where each build represents a feedback-loop around an increasingly larger-grained audience:

  • Private system build, for building a system to use for testing in your private workspace [2]. The consumer for this build is the developer doing ongoing work.
  • Integration build, to integrate all changes in a central place [2]. The primary consumer for this build is the development team, both for the purpose of having additional assurance that the code integrates in a clean environment, as well as for integration level testing in advance of the release of the software.
  • Release build, which packages the software for release. The consumers of a release build are the testing team for pre-release testing, and the customers of the development team for production use.

We noted that each build takes place at different levels of scale. One of the varying levels of scale is that of visibility or organizational scope/impact. Another varying level of scale is that of frequency and duration, or project planning scope. At each level of scale, a slightly different set of needs and concerns must be resolved using a slightly different set of trade-offs:

Build (What)

Visibility (Who)

Frequency (When)

Purpose (Why)

Private System Build

Individual Developer

One or more times per change task

Provide feedback to the developer of the changes just implemented in the private workspace.

Integration Build

Whole Development Team

After each change task and/or one or more times per day (e.g. Nightly)

Integrates the latest changes in the repository and runs automated tests against the release providing feedback to the development team.

Release Build

Independent Test (QA or V&V) Team and Customers

At the end of each iteration/release

Packages release for distribution to the development team’s customer.

An Extra Level of Organizational Indirection
Discerning readers may have

Pages

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at Techwell.com,  and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!