Making builds faster, more efficient

From CitconWiki
Revision as of 15:31, 5 April 2008 by Lcrispin (talk | contribs) (New page: '''Making builds faster and more efficient''' These notes are pretty much in the order in which we talked about the topics. One concept is break the code into parts that build separately...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Making builds faster and more efficient

These notes are pretty much in the order in which we talked about the topics.

One concept is break the code into parts that build separately, each successful build goes to the main project to be built together with the other parts. I’m a little hazy on this but I get the idea. Build several jar files, then combine them into the product.

Other ideas to speed up:

  • If build uses app server, restart it every build.
  • Do cleanup tasks in the interim while the build is waiting to check for the next update and build again.
  • Use ant asynchronous execution.
  • Maven has concurrency built in – promote successful build to central area. Look at dependencies in project.

Parallel execution, task distribution.

Attack slowest area first

One participant described how they use a big pool of machines and split the unit tests across them to run concurrently. Sped up the build from 48 hours to 5 hours. Homegrown tool distributes the work to servers as they become available.

Hardware on build server must be better or as good as what is on developers’ machines.

Tools help manage the process, gather results, add more resources as needed.

Multiple platforms are an added challenge.

Distributed tests with shared resources that developers can use are a good idea.

Hardware – solid state drive faster, if I/O is the limiting factor.

Is the problem only on the CI server, or will it show up on developer machines?

Look at the unit tests. Be smart about which ones need to run when – what value do they provide. Only run the tests that matter.

Lots of small incremental changes can add up to a difference to speed up build. For example, CVS was slow so team went to Perforce, much faster to check out code.

Clean builds vs. Dirty builds

  • Clean builds for production builds – reliable feedback
  • Dirty builds are incremental builds, some people said this was ok for a day, but you needed a clean build at least once a day. Other people said they had good success with incremental builds and even released code that was incrementally built. The latter was thought to be the exception to the rule.

“Sourdough” builds – I need a previous build for this build to work.

  • Dependencies on build-derived objects. Bad.

Tools:

  • Ant – more control than maven
  • Maven does more stuff for you

For continuous build:

  • Cruise control
  • Hudson
  • Electric commander?
  • Buildbeat
  • CI Factory
  • Anthill Pro
  • Pulse
  • Team city

Metrics: Build time on the CI server vs. local – this is useful if you look at WHY? Compile, checkout, tests, server restart, what is slowing it down?

Does every machine have enough resources?

Having someone responsible for the build is important. Ownership.