With ElectricCommander 3.0 set to begin shipping this week, I caught up with Electric Cloud CEO Mike Maciag to better understand the build automation tool's new "preflight" capability. That's a feature that determines whether changes to code will integrate correctly with the main build before those changes are actually checked in.
When I reported on ElectricCommander 3.0 earlier this month, I told you that the tool works by applying an overlay of developer changes through production build and test procedures across all targets, giving developers the chance to commit only if their changes worked. Not content with that, I queried Maciag via e-mail, and he provided some more detail.
EddieC: Can you explain exactly how the tool accomplishes its preflight magic?
Maciag: Here’s how the preflight workflow works: A developer invokes a preflight build and test procedure through the ElectricCommander Visual Studio or Eclipse IDE plug-in. The procedure automatically uploads both the developer’s changes from the IDE and the existing application source code from the SCM tool to ElectricCommander. ElectricCommander overlays the developer’s changes on top of the source code snapshot and executes a build just as if the developer had checked in the code.
The results of this procedure are displayed in the IDE. ElectricCommander can then ‘autocommit’ successful changes to the SCM, or the developer can do this manually. This enables the developer to identify issues instead of introducing them to the code base. It also enables subsequent builds to proceed unimpeded by the result of the simulated check-in.
How is this possible without actually performing a build?
The developer is performing a full build (and tests, too). But they’re doing it in a safe, isolated way that doesn’t impact the rest of the team should the build break or a test fail. It’s the actual check-in of code that is not executed unless the preflight procedure is successful.
You claim that ElectricCommander examines whether changes will affect all possible targets. How does the tool know about all the possible targets and how they’re configured?
That’s the benefit of using ElectricCommander – resources are named, tracked, and classified in the application. ElectricCommander can pool resources (machines) based on common characteristics (platforms, toolchains, etc.). Resources could be a centralized stack of servers, virtual machines, or developers’ desktop machines. So when a procedure (whether preflight build, test, or integration build) calls for a resource, it can call for a specific machine or the next available machine from a pool of like resources. Many build and release teams will set up specific “sandbox” machines for developer builds, leveraging access controls to allow/restrict access to product resources.
Without ElectricCommander centrally managing resources, a developer would typically be limited to his/her local system for building or testing prior to checking in code, which doesn’t work in multi-platform application environments.
ElectricCommander is development-language and build utility agnostic and supports numerous scripting languages, including perl, Python, bash and Tcl. It also works with AccuRev, ClearCase, Perforce, Subversion and Synergy SCM systems.