Search The Blog
My Books

New:

My Songs

 

The Art of Unit Testing

Buy PDF or Print book at Manning

Buy on Amazon

Latest Posts
from 5whys.com
Twitter: @RoyOsherove
About this site

TDD in .NET Online Course

TDD and BDD in Ruby Online Course

 

Subscribe!

This site aims to connect all the dots of my online activities - from tools, books blogs and twitter accounts, to upcoming conferences, engagements and user group talks.

« When I fight with legacy code | Main | Two Day Leadership Workshop–London April 11-12 »
Thursday
Feb072013

Build Pattern: Cumulative Build

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.

PrintView Printer Friendly Version

Reader Comments (1)

I blogged about this quite recently, although I used the term "Layered Builds". I saw it not just about building up layers of artefacts, but also test cases too, such as unit, then integration, then system. Here's my post in case you're vaguely interested:-

http://chrisoldwood.blogspot.com/2013/01/layered-builds.html

February 7, 2013 | Unregistered CommenterChris Oldwood

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Web Analytics