home | products | solutions | services | resources | company | blogs

home > techcorner > What is a Living Build?

What is a Living Build?

Traditional thinking is that every development project has several types of builds that are performed: local development builds, Continuous Integration builds, nightly builds, and release builds. Some organizations may choose to identify additional build types, but the above comprise the typical set.

When we released AnthillPro 2.x (our second generation build management server), we made support for the above listed build types very explicit with a feature called Build Track. All of our example projects came pre-configured with three Build Tracks: Dev (for Continuous Integration), Nightly, and Release. We are largely responsible for (if not introducing) reinforcing this view of distinct build types.

However, our experience over the years with build management and application lifecycle management has taught us that there really are only two types of builds: local development builds and authoritative builds (that take place on the build management server). Continuous Integration, nightly, or release builds are not differences in the types of builds, but differences in the stage of the build lifecycle. A build may start out as a Continuous Integration build designed to run only the most important automated tests to verify the build (the focus being on providing quick feedback to the development team). The latest successful build for any day may then run through a more exhaustive test suite during the night and thus become the nightly build. And due to a large number of factors, such as the features included in a build, the time line of the project, etc., a build may become a release build. Perhaps it will even be deployed or promoted to the QA environment.

AnthillPro3 takes a different (and completely new) approach to thinking about builds. Rather than having different types of builds (which we believe is the wrong approach), AnthillPro3 treats Continuous Integration, Nightly, and Release as different stages of one Living Build. Instead of treating a build as a discrete event, we realized that there is a whole lifecycle that may be associated with each snapshot of the project sources. This lifecycle starts with the process that takes the sources as input and produces binaries as output. It may progress through various forms of testing of those binaries, promotion, and deployment. Finally, it may conclude with a release of those binaries into production. What we (as an industry) have traditionally referred to as the "build" is really just the beginning of that lifecycle. It is the start of the Living Build.

Builds and Build Types

To explain the concept of a Living Build, lets back up a little and examine what is a build. A build, within the context of AnthillPro3, is a process that takes a very specific type of input (the source) and produces a very specific type of output (the build artifacts). The idea behind a build is that it is a transformation of the project source files into artifacts as they exist at a particular point in time (sometimes also called derived objects). Once the build artifacts are available, they can be used for other purposes such as running additional tests, deploying, packaging for release, etc. Or, said in a different way: once a Living Build has artifacts, other stages of the Living Build can act on and use those artifacts. For example, the artifacts may go through a build verification stage of the Build Life; a stage that deploys the artifacts to the DEV environment; a stage that deploys the artifacts to the QA environment; or to production.

Traditional approaches to build management take a slightly different approach to a build. In the traditional model, the "transformation" that is applied by the build is only the first part of the build. There is a second part to the build that applies some additional process to the artifacts produced by the transformation. This additional process varies based on the type of build. So a Continuous Integration build would apply one additional process (running of an abbreviated test suite) and a nightly build would apply a different additional process (running of the exhaustive test suite), and a release build would apply yet another process (apply label and deploy).

There are two main problems with this traditional approach. First is the fact that the project files are in a constant state of change. This means that the files that were used by the Continuous Integration build are most likely different than the files used by the nightly build, which are different than the files used by the release build. Even if the build management system overcomes this problem there is still the challenge that every build type produces its own artifacts. The Continuous Integration build produces the artifacts that it tests. The nightly build, even if it does manage to use the same sources as the Continuous Integration build, will still produce its own artifacts. And the release build, even if it too manages to use the same sources, will create yet its own artifacts.

The problem with this approach is that the artifacts being deployed by the release build are not the ones that were used in the exhaustive test suite that was run during the nightly build. For these reasons, the standard approach of using different build types (Continuous Integration builds, nightly builds, release builds, etc.) is imperfect.

AnthillPro3 takes a different approach. Rather than having different build types, each with a different additional process, AnthillPro3 separates the transformation used to produce the artifacts from the additional processes that are applied to those artifacts. All of these pieces, the transformation as well as the additional processes, are then linked together via the Living Build. So rather than having a Continuous Integration build type, AnthillPro3 has an "Abbreviated Test" stage of the Living Build. And rather than having a nightly build type, AnthillPro3 has an "Exhaustive Test" stage of the Living Build. And rather than having a release build type, AnthillPro3 has a "Promote and Deploy" stage of the Living Build.

Benefits of Living Builds

There are many benefits to the Living Build concept. The major benefit is a guarantee that the same exact artifacts are being used for each additional process (abbreviated test suite, exhaustive test suite, release, etc.). And since the same exact artifacts are being used, then there is a guarantee that the same exact sources were used to generate those artifacts.

Perhaps the greatest benefit of the Living Build approach is the new way of thinking about builds. We are no longer constrained by the build type approach, under which applying a new additional process requires reconfiguring a new build type and then executing it to create a new build. This would first recreate it's own artifacts before applying the new additional process to them. With the Living Build approach, if you want to apply a new additional process, all you have to do is define the additional process, and then you can apply it to any existing Living Build. There is no need to execute new builds. In this way, the traditional view of builds is very static and discrete, where each build has a definite start and end point. Whereas the Living Build approach is dynamic, with each Living Build beginning with a snapshot of the project sources, but with no end to the additional processes that can be applied to it.