Today continuous integration is used by the majority of professional software developing companies. As a developer it’s nice to have an almost instant feedback after your commit. From the sight of a software architect or manager it’s nice to have a real time monitoring. We all know the advantages of a common build server. But what about the downsides?
Especially if a team starts working with a continuous build server for the first time, it can raise a few questions.
I want to discuss one of those questions in detail.
- Do I have to run a private build before my commit?
The following assumptions will help us finding an answer to this question. The build server is configured to compile all sources and run all unit tests after every commit affecting a certain project. Let’s assume this takes about ten minutes.
Some team members claim that others break ‘their’ build. The breakers will further avoid breaking the build again, because they don’t want to be on the pillory again. This leads to a bad atmosphere. And furthermore, there will be wasted time.
I want to explain this provocative statement in detail. Imagine a team of 20 developers working on a single product. Every developer does two commits during a normal day. If every developer runs a private build including all unit tests, this would mean a time investment of 400 minutes a day.
But we know all of our developers are good developers. They know what they do and they care about their work!
If they would just compile the solution they’re working on, they would only need two minutes instead of ten minutes. Why should they run a private build before their commit?
If they break the build they can take a look into the report and care about everything that’s broken. But if they don’t break the build, they saved eight minutes.
Given a theoretical situation where every commit is perfect, you could save up to 320 minutes a day. I know this ideal scenario is not realistic. Let’s assume that we need 20 minutes to solve a build failure and guess what, we’re not perfect.
The following table shows the potentially saved time compared to the failure rate. Every failed build will cost 20 minutes to be resolved.
| Failure rate | Time saved |
| 10% | 248min |
| 20% | 176min |
| 30% | 104min |
| 40% | 32min |
| 45% | +4min |
| 50% | +40min |
If you manage to have a failure rate below 40%, which should be very easy to achieve, you’ll save 32 minutes a day which makes more than 10 hours a month (based on 20 business days a month) or 128 hours a year.
Why do we have a build server? Because it’s there to break. If we don’t use the power behind this infrastructure, we maybe don’t need it anyway.
But wait, I cannot work, if the build of the trunk is broken!
Well only because the build of the most recent version of the trunk is broken, it doesn’t mean that you cannot do any work anymore. It’s just as it is. The build has failed. Because we have the comfort of a build server we know which version was the last stable version. We can easily update to that particular version and carry on working as if the build would have built correctly.
Modern continuous integration server like TeamCity allow you to mark a failed build for investigation. This way you can tell the other team members that you are looking into the problem and anyone else can ignore that failure. This helps to save time again.
And now, please tell me, if you do private builds before your commit? And will you carry on like that?
It is relative to say that is easy to achive bellow 40% failure rate. If I have private build I don’t have to have a top priority of fixing the broken builds. By example if I have a private build I brake the build but I don’t rush imdediatly to fix it because I would like to focus on somethink else or I have a meeting, etc.