|
|
Line 1: |
Line 1: |
− | '''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.
| |