Note: This will become part of my book on beautiful builds. Any comments or feedback are more than welcome, as well as ideas of other common build patterns you see in the wild.

Other Names:

• Distilled Build
• Inherit/share/import Artifacts
• Borrow Build Artifacts
• Pre-Chewed Artifacts
• Single Responsibility Build Configuration

Symptoms:

• Your build configuration on the CI server is taking a long time to complete.
• Each Build Configuration down the build chain takes longer and longer than the build configuration up the chain

Problem:

Your build config might be doing too many things.

Forces:

You want your build time to take less, but you do not want to remove any actions from the build because all the build actions are important.

Solution:

First, Have each build configuration do one thing, and then “share” the resulting artifacts, such as built binaries, so that other build configurations can use them.

Then, for each build down the pipeline, have the build import the artifacts from the build config up the line, and simply do one more action on the artifacts, and share them with the next build up the pipeline.

For example

say you have the following build configurations in TeamCity before applying the solution:

• Continuous Integration Build : Gets from source control, compiles in debug, runs fast tests in debug
• Nightly Build: Compiles in debug, runs tests in debug, compiles in release, runs tests in release, runs slow tests on release, deploys to test env.
• Release Build: Compiles in debug, runs tests in debug, compiles in release, runs tests in release, runs slow tests on release, deploys to release env.

Here is one way we can make each build do one thing, then share the artifacts with the build up the pipeline:

• Continuous Integration Build : Gets from source control, compiles in debug, runs fast tests in debug, shares source and binaries artifacts
• Nightly Build: Gets build artifacts from CI build. Compiles in release, runs fast tests in release, runs slow tests in release. Shares binaries as artifacts.
• Release Build: Gets build artifacts from nightly build, deploys to release env. Shares deployed binaries as artifacts.

Now, each build does just one thing, on top of the pre built binaries. For example, only the first build of the bunch gets from source code. Only two builds compile. The deploy build doesn’t do anything but deploy.

This also eases the build script management, each build gets a separate build script in source control, that can be reused if needed.