Build Avoidance is a feature of Meister
Build Avoidance a critical part of continuous integration
In a recent article, the term “Build Avoidance” was referenced as if it was something new and improved. NEWS Flash! Build Avoidance was a term coined by IBM and referenced the way in which ClearMake handles Incremental Build processing, meaning only re-compile what has been updated and AVOID the rest.
“Build Avoidance” should be a primary function of your continuous integration solution. It is not “new” by any means. The biggest challenge with “Build Avoidance” is to support it for all languages from Unix C to .Net and Java. For example, the “gnumake” based scripting languages only supports C/C++ languages. Ant/Maven scripting supports “pseudo incremental builds” which really is the opposite of what you would think. Maven’s “pseudo incremental builds” does a “clean all” on the Projects that have changed, not on just the source code that has changed. Doing a “clean all” is not avoiding a build it is making sure that objects will be rebuilt by deleting them.
Meister has supported Build Avoidance for all languages for over 21 years. Only OpenMake Meister can actually make the claim for C/C++, .Net, Java and yes even COBOL.
So the moral of the story is, if your build automation tool is not supporting Build Avoidance, or some how touts that this is a new concept, you should look for a better build solution for your continuous integration process. Build avoidance is the process of executing a build with full knowledge of the dependencies and which dependencies are out of date and need to be re-built. This is a core function of build automation. The best way to speed up a build is to not recreate object that are already available.
As long as we are on the topic of Build Avoidance, lets bring up how critically important Build Avoidance is to your Continuous Integration process. Remember – your Continuous Integration process is only as good as your build scripts. To improve your CI process the engine that drives your compile and link process must be “smart.” What does “smart” mean you ask. A smart build knows more than you do about how your application is put together. This means that is understands the dependencies (compile, provided, system scope, etc). With those dependencies is can accurately rebuild your application by only updating what has been changed.
Yes, you can do this for Java, .Net or any native language such as C/C++. What does this buy you. First, in most cases your CI compile and link step will execute in less than a few minutes. Secondly, you are given a platform for doing pre-flight builds where any developer can re-compile the entire application, locally, without wasting an hour (or a few hours).
If you want your CI process to run really fast and accurately, make your builds “smart” so you don’t have to run “clean all” every time you execute a pre-flight or CI build. Hey it is 2010 already. Start using your computer to orchestrate your compile and link process and stop writing static scripts that lack the ability to support your development process without your constant attention. This is real build automation.