The Obvious But Ignored Way To Save Money (And Increase Productivity)
Waiting for check-in to complete and tests to pass on a Continuous Integration environment is wasted time and money. CI build can take seconds, minutes or even hours. The longer a build takes, the less frequently developers are willing to check-in their results. It is the return of the "It works on my machine" approach. The chance for conflicts and for integration challenges is increasing, their resolution is another opportunity to waste time and money.
For unknown reasons no-one usually cares about the performance of a CI build. In contrary: we usually get the slowest machine available as CI server what makes the CI-experience even worse.
How to really save money?
The calculation is simple: If 10 developers have to wait 0.5h a day for the CI to build, 5h a day are wasted. An investment of a 8 core I7 machine with > 16GB of RAM and a RAID 0 array of fastest available SSDs should amortize in a week.
Pro-active profiling and tuning of a Continuous Integration environment saves even more money. Every second spent to wait for a feedback from a CI is wasted time.
In a midrange project even a dedicated person who just cares about build performance should easily pay off.
The idea of saving money on CI hardware / infrastructure is even more mystical to me, than attempting to be extensible with Impls :-).
See you at Java EE Workshops at MUC Airport--with less esoteric topics :-)!
Thanks for the good read!
Most of my Jenkins builds write their duration to a file. Build times are then plotted with a plotting plugin. This makes it obvious when the build starts to slow down so we can intervene.
Suggested approaches for fast build times are pretty much the same as those for writing clean code:
1. Many small projects & builds are better than one big pile of steaming poo.
2. If it grows too large/slows down, split it.
3. Not every step of the build has to be executed on every commit. Slower steps, like static code analysis can be run nightly instead.
Posted by Nim on January 12, 2013 at 06:26 PM CET #
@Nim,
Actively tracing the build performance is a good idea!
I'm not fully agreeing with #3. I would rather execute static analysis in parallel. I heavily rely on some metrics, like e.g. code coverage or cyclo complexity to find superfluous or too complex code.
#4: invest first a reasonable amount of time and money to the build machines.
thanks!,
adam
Posted by Adam Bien on January 14, 2013 at 09:22 AM CET #
On the pro side, you can make use of the time during the CI build and read and comment on some blogs :)
Posted by tine2k on January 15, 2013 at 11:36 AM CET #
waiting for the build-server's web-ui to respond while reading this...
Posted by 93.159.251.2 on March 05, 2013 at 01:44 PM CET #