What is a Living Build?

A Living Build is an AnthillPro concept that treats builds not as distinct events but as part of a series of hands-offs from one stage to the next. The Build Life represents all the transformations a build has gone through, and traces that build back to the originating source. In effect, the Build Life (or a Living Build) is a map of what occurred during the build. A Build Life can then be thought of as a way to exactly trace a build back through its life to reveal all that went into it, as well as a way to revisit a build should you need to perform additional tests, etc.

Living Builds, implemented as Build Lives in AnthillPro, provide traceability of artifacts from the pure build processes (originating workflows) producing the artifacts to the secondary processes (non-originating workflows) acting on the artifacts. Every Living Build must start with a pure build process that produces artifacts. Those artifacts are then forever associated with that specific Living Build instance. As AnthillPro runs secondary processes on the originating workflow, it implicitly use artifacts associated with the Living Build, thus providing traceability back to the source.

Why 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.

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 with a focus 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.

AnthillPro introduces a new approach to thinking about builds. Rather than having different types of builds, AnthillPro treats Continuous Integration, Nightly, and Release as different stages of one Living Build. A build is not a discrete event. 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 the industry has 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

A build, within the context of AnthillPro, is a process that takes a very specific type of input — the source — and produces a very specific type of output — the build artifacts. 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.

AnthillPro takes a different approach. Rather than having different build types, each with a different additional process, AnthillPro 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, AnthillPro has an "Abbreviated Test" stage of the Living Build. And rather than having a nightly build type, AnthillPro has an "Exhaustive Test" stage of the Living Build. And rather than having a release build type, AnthillPro 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.