views:

98

answers:

2

When i say “time” I am including everything that happens in a build (compilation, unit testing, code coverage, static analysis etc)

I guess what I am getting at is what is the build time threshold before I should look at either upgrading hardware or splitting up into smaller builds.

At the moment I am leaning towards 5 minutes.

+1  A: 

We actually have explicit delays set in our continuous integration server (Hudson) so that the builds don't "break" if multiple commits are needed in order to bring the repository back to a usable state (I'm talking about multiple commits over the course of like a minute). For example, you may have multiple projects that depend on each other, and they each need to be committed, or you may have different pieces of code that should be committed separately, as the changes are logically independent.

One of the primary goals of continuous integration is to make sure that nothing breaks inadvertently, and in particular make sure that if something does break, someone finds out as soon as possible. It is a whole lot quicker and easier to fix an issue at a point in time closer to when the issue was created, than later on when a developer finally gets around to doing a build.

Additionally, the mere presence of a continuous integration (build) system has the tendency to keep developers on their best behavior.

So as long as your builds aren't taking hours, that's probably fine.

Adam Batkin
+2  A: 

5 minutes is a good starting point. I've had projects that took 12-15 minutes to build with a 6-person team. Our rule was not to commit to a building project nor a broken build that you didn't break. Commits could only happen every 12-15 minutes and this became a problem. We invested in better hardware and split the build into 1) build and unit tests and 2) acceptance tests and code quality checks. We amended the rule to allow another commit after step 1 that was now around 5-6 minutes.

Another factor to consider is how soon after a commit you'll be leaving your work environment for lunch, a meeting, or for the day. I remember committing at 6pm and having to wait until 6:20 to leave. There were times where I waited until the morning to commit.

So the two factors are:

  • How long between commits?
  • Is the build time so long that devs avoid committing?
Ed Chapel