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.


TRagan

Ms. Ragan has had extensive experience in the development and implementation of DevOps for large organizations. She began her consulting career in 1989 on Wall Street specializing in build, testing and release management for the distributed platform. It was during her consulting experiences that Ms. Ragan recognized the lack of standardized development procedures on open systems that were common on the mainframe. In the years leading to the creation of OpenMake Software she worked with development teams in implementing a community driven standardized build and deploy process that enabled frequent builds and releases, automated around version control. Her knowledge and experience contributed to the creation of OpenMake Meister, the first commercial Build Automation solution. Ms. Ragan served on the Eclipse Foundation Board of Directors as an Add-in Provider Representative for 5 years. She has been published on numerous occasions and regularly speaks at conferences including CA World where she presented for 15 consecutive years. She holds a BS Degree in Business Administration, Computer Technology from California State University, Pomona.

0 thoughts on “Build Avoidance and Continuous Integration”

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts

DevOps

Cross Platform continuous delivery

Cross Platform Continuous delivery, from windows to z/OS Cross Platform Continuous Delivery – DevOps at full strength Cross Platform Continuous Delivery for the Enterprise is supported by Release Engineer and Meister Cross platform continuous delivery is a requirement for the Read more...

DevOps

Application Release Automation with Ansible Galaxy Roles and Release Engineer

Application Release Automation requires the ability to manage both the application stack and server configurations. IT Engines such as Ansible are designed to manage server configurations and the IT Stack, but do not focus on Read more...

DevOps

Debugging Microservices

I am in the process of moving DeployHub Pro to microservices for our SaS offering and I ran into an interesting dilemma. Microservices are great for having small contained pieces of functionality for scalability and Read more...