Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
A good build tool and process should not perform needless and redundant time-consuming work on unchanged sources each time the build runs. In other words, it should only do the work required to apply the results of the source modifications to the build artifacts. If your build tool or process doesn't exhibit this behavior, then think about optimizing your builds by avoiding the needless work.
For example, assume we have a bottom-up build process—our project is built from a persistency layer up to higher layers. Usually, these kinds of projects have long builds caused by the code-generation and reverse-engineering tools used in them. As illustrated in Figure 1, first, the build process runs a SQL script on a database management system (e.g., MySQL) to create the database and fill it with sample data. Then, the Middlegen task runs to generate CMP (container-managed persistence) entity beans. Then the XDoclet task runs to generate remote, local, and home interfaces, value objects, and deployment descriptors for the CMP entity beans generated in the previous step. (For more on XDoclet and Middlegen, see Resources.) Next, this generated source code plus developers' written Java source code are compiled, and these compiled class files plus other resources are packed in jar, war, and ear files.
Figure 1. The sample build steps and outputs
Now assume that a developer working on this system's source code has slightly modified an if-else block and wants to see the results of his change. So he does a rebuild. A clean build erases everything generated by the previous builds and builds everything from scratch. For the developer, that means minutes of waiting and standing idle for a simple recompilation of the modified class and then an update of the relevant jar or war file.
In this article, I introduce some techniques to save you time by preventing redundant rebuilds of up-to-date sources and doing faster builds on outdated sources.
To begin our discussion, let's consider continuous integration, the strategy of ensuring that changes to the project's codebase are built, tested, and reported as soon as possible after they are introduced. This reduces the costs and time needed for development teams' integration sessions. This process requires:
Let's look at the overall picture (illustrated in Figure 2) of a development team utilizing this discipline and the activities developers do in such teams. Each developer has a local working copy of the project. Before starting the new task assigned to him/her, he updates his local copy with the changes committed to the codebase, accomplishes the newly assigned task (changes some portions of code, for example), updates his working directory with possible changes during his development session, does a build, executes the tests, and, eventually, if all tests execute successfully, commits the changes to the codebase.
|Forum migration complete By Athen|
|Forum migration update By Athen|
|maven incremental builds By Anonymous|
|What about maven? By TrippleT|
|Incremental and fast builds using Ant By JavaWorld|