| Written by


I’m a big fan of continous integration, and build automation. Having a server run a full checkout, produce a build, run your units tests, and then bundle your entire project into a distribution package is a huge win. For continuous integration having this trigger on a check-in to your VCS is crucial. It highlights errors while they’re still fresh in a developers mind and leads to a quicker fix.

What’s baffled me is why use a scheduled build? What is it’s value in a continuous integration environment? Until last week I didn’t have a decent use case (and so I didn’t use them.) However, I’ve finally discovered a use case for them:

At work the current build setup is as follows:

  • Project 1
    • Sub-project 1A
    • Sub-project 1B
    • Sub-project 1C
  • Project 2
    • Sub-project 2A

During development the team realized that Project 1 required an update to an external dependency. The team made the upgrade on our local machines, ran our tests and everything looked good. I then made the upgrade on the build server, ran all the builds and units tests – everything compiled and worked. I happily marched on my merry way.

However I didn’t run builds for Project 2. And as it turns out Project 2 was on a two week code freeze (that sounds funny in a CI environment, but it was a valid reason for a freeze.)

After their freeze finished the build failed on thier first code check-in. The error was bizarre, and they had to spend some time looking into the problem. After not finding anything they rolled back the change expecting the build to succeed.

Wrong! The build failed again. So more time was spent diagnosing the problem and it turns out that the external dependency I upgraded in Project 1 conflicted elsewhere in Project 2.

I had never thought to run Project 2’s builds because the two projects had enough separation that the dependency change shouldn’t have mattered. And of course the email I sent to them saying “If you notice any weird issues in the build let me know” was completely forgotten about – that’s my fault not theirs, because no one remembers those emails!

So lesson learned. More than a few hours of work could have been saved if we ran Scheduled Builds.

This also highlights one of the huge benefits of continuous integration and build automation. You don’t realize how beneficial it is to team until it isn’t highlighting problems.

Before CI software development must have been like the stone age!