Builds and Releases

A Build is change or collection of changes, integrated into a product, that has had some (typically minimal) level of inspection and quality assurance.

A Build may be performed at an individual personal level or at a team level where changes from more than one team member are integrated into the build. Inspection and quality assurance activities are normally a little more involved at team level as the Definition of Done is a little higher but builds do tend to have a relatively low Definition of Done – not every build will be fully tested. Builds happen frequently, often many times a day.

A Release has a dual nature:

  • a Build, with a high level of Done, packaged for operational deployment that is a viable cohesive product delivering Business Value.
  • a Planning concept (Release Plan), typically containing a number of deliveries produced through, iterations/sprints or continuous flow, that combines a set of “done” high level-requirements, architecture and tests – often represented as a Milestone.

A Release is typically formed once in a Release planning timebox after a succession of internal builds but can be created from every successful team build when Continuous Deployment practices are used. Releases will reach a high Definition of Done, often as far as “End 2 End Tested” but may not necessarily be adopted by the business just because they are ready as Adoption and Business Change cycles may be decoupled from Release cadences.


Personal Builds will happen very frequently, at a developer’s discretion, and are not formally tracked. They may well fail and such failures are simply part of the local software development technical practices – they should not be reported. Developers using compiled languages will often build simply to check their syntax and run IDE based code analysis – maybe never actually running a personal build. Team Builds tend to follow successful Personal Builds when a developer pushes their changes or an integrator pulls them into an integration stream or automated build server (see Continuous Integration).

Personal Builds tend to happen at the “Developed” level of the Definitions of Done, whereas Team Builds tend to happen at high levels of integration and Definition of Done.

A build may apply to a component, system or system-of-systems and represents proof  that the code elements pass inspection and some limited quality assurance. In the case of non-compiled languages, a build may be harder to define, especially at a personal level, however since personal builds are not tracked or reported that tends not to be important. We recommend that a basic level of developer testing, unit testing and/or static analysis is done prior to promotion of changes to a team Build level, even for non-compiled languages.

We recommend that team builds are frequent, preferably daily or continuously (see Continuous Integration). ). A Build may not be a releasable version of a product or product family. The purpose of frequent builds is to ensure that the collective changes that make up software are in a working state (and haven’t introduced “regressions” or Problems). If the interval between working versions is short, then finding the cause of bugs is relatively easier (and can even be done by “binary bisection”) making defects easier to fix or simply discard rather than fix.

Personal Builds will typically not affect a Product version number, whereas a Team Build might affect the very last part of a version number (e.g. 2.3.67).

Builds are the smallest form of feedback cycle in Holistic Software Development and therefore the earliest opportunity to prove value, reduce risk, verify and validate the product at both Product and Product Family Level.

Technical Development practices such as Test Driven Development, Pair Programming and Mob Programming can even move the feedback, verification and validation into the code production activity prior to a Build although they are no replacement for actually running working software.


A Release is a version of a product which has met enough high-level requirements to deliver sufficient business value that the product could be adopted by the business and deployed operationally. This means that Releases must have a high level of Done, typically as far as “End 2 End Tested” and even into “Business Acceptance”. While a Build typically integrates a number of low-level requirements to a minimal level of Done, a Release delivers a number of high level requirements to a high level of Done. A Release delivers  Business Value.

A Release (via a Release Plan) is also the bridge between planning phases (and therefore often contractual phases) and high level requirements such as Integration Scenarios and Features, or sometimes other Scoping Diagram elements.

These plans and requirements come together, through product delivery and integration into a Release – an implemented version of a Product or Product Family. Since a Release as a planning construct defines a scope in terms of the requirements it also bridges planning with architectural achieving risk reduction through working software.

A Release is the physical realization of a significant milestonein a development lifecycle. Releases are the heart of any development endeavor and so the heart of the H-Model. We recommend focusing planning, process, architecture and adoption efforts on Releases.

A Release represents a significant achievement for the development team, however not every Release will be deployed operationally as Release cycles may be de-coupled from Adoption and Business Change cycles. However, Releases that are not deployed carry quality and validation risks, despite acceptance activities so we recommend that adoption and release cycles are kept reasonably in sync. The only way to actually mitigate risks is to use working software in real situations, testing can only indicate not prove quality.

Continuous Deployment practices involve every releasable version of a product being, often automatically, deployed operationally. Continuous Deployment can be difficult for business users to become comfortable with, as from their perspective, the product can change every time they use it, however if deployment is truly continuous then user facing changes are typically small and can be easier to adopt than a large set of changes requiring user retraining.

Importantly, Continuously Deployed products have their quality assured continuously, meaning feedback can be continuous and so are far more responsive to change.

Very early Releases may be focused on proving architectural approaches and may not be viable products from a customer perspective, however early architectural releases are significant achievements for any development and we strongly recommend their use in conjunction with a risk driven approach. Despite not being viable products they are important points for feedback and course correction. We recommend that any release, including these very early releases is requirements based and delivers at least one functional requirement to avoid architectural gold-plating becoming divergent from requirements.

Releases will typically affect the major numerical or named parts of a version number/label  (e.g. 2.3.67).

Releases are a critical point at which planning, requirements, architecture, testing, and customer validation come together enabling feedback cycles throughout the Software Development organization.

Release planning is commonly dysfunctional in complex software organizations, in part due to the duality inherent in the concept of a release. Holistic Software Development aligns the various concerns at Product and Product Family Release levels through Requirements, Architecture, Integration Streams, Reporting, Environments and Definitions of Done – all cohesive at horizontal layers of the Big Picture.

The idea of a Minimum Viable Product (or MVP) has recently become popular to describe “a version of a product that allows a team to collect the maximum amount of validated learning about customers with the least effort” – Eric Ries.

 Read more: Minimum Viable Product

Integration Streams combine the output of multiple developers, and/or from multiple contributing teams in a complicated or complex system. They also provide a staging mechanism for testing prior to promotion from “build” to “release” enabling progression through the levels of done. Integration Streams are typically implemented as “streams” or “branches” in version control tooling.