I've always launched builds after each commit, but on this new project, the architects just asked me to change the frequency to "one build every 15 minutes", and I just can't understand why that would be a good reason vs "building on each commit".
First off, some details :
- Objective-C (iOS 5) project
- 10 developpers
- each build actually takes ~1 min, and includes build and unit testing.
- the integration server is a Mac Mini, so computing power isn't really a problem here
- we use Jenkins with the XCode plugin
My arguments were that if you build at each commit, you can see right now what went wrong, and correct directly your errors, without bothering the other devs too often. Plus our tester is less bothered by UT errors this way. His arguments were that devs will be flooded by "build error" mails (which is not completely true, as Jenkins can be configured to send a mail only for the first broken build), and that metrics can't be done properly if the frequency of builds is too high.
So, what's your opinion on this ?
Best Answer
Fail fast is a good principle - the sooner you know the build is broken, the sooner the offending commit can be identified and the build fixed.
Build on every commit is the right thing to do.
Building every 15 minutes can be pointless if the project has a high volume of commits within such a timeframe - tracking down the bad commit would take longer and may be difficult to determine (one might also be in a situation where multiple commits have different things that break the build). There is also the possiblity that in quiet times (night time?) you end up rebuilding though no changes have been made.
If the build breaks so often that it is a problem, the answer it to re-educate the team on the importance of not breaking the build and in techniques that ensure this does not happen (frequent fetches, checkin dance, compiling and running unit tests locally etc...).