Electric Cloud creating a Build storm

Reg Dev: So, what is different now?

Patterson: It was difficult to address the back-end problems until two key technologies became available - the web, for access and sharing, and cheap rack-mounted servers for scalable computational power. The web has been available for about 10 years now, but rack-mounted servers just became cost-effective a few years ago, they are now dropping in cost rapidly. A lot of what we have done at Electric Cloud is to figure out how to harness these technologies for builds and other back-end tasks (for example, without our automated dependency management technology there is no reliable way to use server clusters to run builds in parallel).

Another reason builds are garnering attention right now is the move to agile development. One of the key principles of agile development is frequent integration and testing, both of which depend upon reliable and efficient back-end processes. Many organisations are trying to become more agile, but discover that they cannot do that without major improvements in their back-end processes ("you can't do agile with long builds").

For example, Intuit uses ElectricAccelerator to rebuild the QuickBooks software product automatically every 30 minutes all day long, every working day. This allows them to detect and fix errors very quickly, so that overnight production builds virtually never fail.

Reg Dev: So, how do you integrate with the different ALM toolsets that are available?

Patterson: ElectricCommander is our primary point of integration with the rest of the ALM tool chain. The natural handoff point between the front end of ALM and the back end build and release process is at SCM. When code is checked in, build and test cycles should commence in a seamless and automatic fashion. So we have out of the box integrations with tools like IBM Rational ClearCase, Perforce, AccuRev, etc, and are building out integrations with automated test solutions as well.

Reg Dev: And what is your position on Eclipse versus Microsoft's VSTS? Do you support open frameworks such as ALF?

Patterson: As a company we've not taken an either/or approach, though we've certainly observed the rise of Eclipse as more of a framework than is the case with Visual Studio. The growing ecosystem of Eclipse plug-ins is certainly testament to that.

Both of our keystone products support Visual Studio builds, and ElectricAccelerator distributes and accelerates native Visual Studio builds to deliver 8-20x speed improvements over a sequential build. What's more, our ElectricCommander build and release automation solution leverages the Eclipse BIRT reporting framework, which is rapidly becoming industry standard.

We're watching the Eclipse ALF project with great interest. It sounds like a promising way for best-of-breed ALM tools such as ours to interoperate in a standard fashion. But to be quite frank, we haven't seen a demand for this among our customers. We typically work with large enterprises, and so wide adoption of something like the ALF framework may be slow in coming.

Reg Dev: Now, at a slightly lower level, what about feedback of useful management information from the build process?

Patterson: For any team, the build-and-release process is where all the pieces come together - or not - and thus it can be a definitive measure of a project's overall health. The builds become the "heartbeat" of software development. So providing reporting and visibility into build processes (via dashboards, charts, reports, etc.) gives a leading indicator of progress. Even providing red and green lava lamps (red indicates the most recent build has failed) or a "stop light" chart on a big screen monitor gives everyone in the development organisation instant understanding of whether the project is on track or not.

With geographically distributed teams, this information becomes more critical. Historically, nightly builds were the norm, but with teams in multiple time zones, there is no night. Each team in each location has to have information such as "which was the last clean build", "from which branch they should be building", etc.

We've built a reporting engine into our ElectricCommander tool for just this purpose, again based on the Eclipse BIRT framework. We specifically chose this approach so teams could extend the reporting to extract the information most useful to them, and to also enable them to pull that data into the commercial reporting product they already use (whether something like Actuate or Crystal Reports, or even Microsoft Excel).

Reg Dev: Does your Build toolset enable increased transparency through from physical code to the business requirements?

There is more and more pressure to provide full traceability of code backward from the released application (or "gold master") all the way back to initial code creation, for example: What went into this release? What bugs are fixed? What packages are affected?). So providing a manifest or "bill of materials" is essential (and fairly impossible with a completely manual build infrastructure).