Build Forge Briefing

Last week Anne and I talked with folks from (now) IBM’s Build Forge. The topic was ostensibly continuous integration, but naturally expanded into Build Forge as a whole and the context of builds.

Builds!

Build Forge provides what you might call a “full plate” build management system. As fellow Austinite Doug Fierro (Director of Build Forge Product Management), said, it’s really a framework for doing builds. In use, this means Build Forge will perform not only “traditional” builds, but also do continuous integration, release builds, and provides enterprisey features like audits and role-based access to aspects of and the build as a whole.

Enterprisey

As I look at more and more build systems, that last part is what often separates the open source build systems from the closed source, commercial systems. This is understandable as the open source build systems often come from and are driven by purely developer desires. Developers don’t care too much about auditing and compliance beyond the “you broke the build emails” that Cruise Control and others create. On the other hand, if you have compliance desires (with security, process, and even accounting), you’ll need a build stack that keeps track of and reports on who did what.

Also, in the enterprisey vein, we talked about some customers use of Build Forge with out-sources. The situation here is one in which the team is a mix of in-house and out-sourced coders. In that case you may want to limit the access the out-sources have to certain parts of the build. Or, at the very least, keep track of who access what. Clearly, that concern bleeds into your version control system (like CVS, subversion, or ClearCase), and I didn’t drill down enough on that point to get all the details.

Build Farms

Another differentiator for Build Forge was its agent-based method of creating build farms. While there are other, open source systems that do this, from what heard at ApacheCon this year, most of them are not too easy to use. That said, I don’t know how “easy” Build Forge’s agents and the resulting build farms are, but theoretically you can get rich support in figuring them out.

Why would a build farm matter? For a few reasons:

• Performance – doing “threaded builds” to speed up any given build, load balancing each node in the build clusters, and then providing high availability (of the fault tolerance variety, not the other one).
• Native Builds – as needed, different parts of your build can be made on different platforms. For example, in systems management work, you’ll end up needing some Windows code eventually, and those DLLs don’t build on *nix boxes, brother.

The Shame Avoidance System

One of the more intriguing (and differentiating for Build Forge?) results of using a build farm was the ability for individual developers to do test builds on the build farm before committing their code. While it’s fine to do a test build on your own boxe(s), the same ones you wrote the code on, every developer and team has experienced reoccurring cases of Works On My Box Syndrome:

That is, you do a build, run tests, and everything works. So you check in the code. Then the build breaks. “What?! Impossible!” you say, “…works on my box!”

So, by using “pre-commit builds” developers can take their new code and test it out on the official build farm, avoiding the shame of an unsightly case of Works On My Box.

RedMonk Advice

As always, I couldn’t help but make a few suggestions:

• Given that Build Forge is a framework, it’s perfect for selling configuration and best practices around. That is, while some shops could truly benefit from a highly customized build, the reality is that the Maven theory of builds applies in most cases. The Maven theory of builds is much like the Rails theory of conventions and constraints: the framework chooses how to do a lot of things for you and by doing then that way, you’ll save time by avoiding all that low level stuff. This is not to say that Build Forge would enforce a limited number of ways to do a build, but rather they’d provide several out of the box build environments and processes. This, of course, is something that IGS and partners could sell. More broadly, it’d be a great way to extract an Express line out of Build Forge.
• Look for chances to integrate with and use Mylar. As you know, dear readers, I’m exuberant about Mylar. In the case of Build Forge, it’s not only the nascent ALM parts that look appealing. In the present, the context sharing seems applicable to fixing failed builds. For example, if a build failed, Build Forge could immediately create a Mylar context, create an associated task to fix the broken build, assign it to the person who broke it, and attached the context. In this case, the developer(s) fixing the build could use Mylar to immediately set their code-context to everything (and only everything) related to fixing the build.

Notes

Here’s the mindmap of my notes:

Disclaimer: IBM and Eclipse are clients.

Technorati Tags: ibm, buildforge, builds, mylar, eclipse, redmonkadvice, enterprisey