July 24, 2013

Pre-flight Builds and Perforce

Helix Swarm
Traceability
Version Control


Image: Official U.S. Navy Imagery W/Flickr

 

If you're a true believer in Continuous Integration (CI), you’ve probably tried to run pre-flight builds.  A pre-flight build lets you run a pending change through the official CI machinery before you even commit a change, giving you better confidence in your work and helping to prevent broken builds.

There are several ways you could attempt a pre-flight build with Perforce.  I’ll cover a few of those here, along with an idea for a purely local build in cases where the build takes a very long time.

An easy option to start using pre-flight builds is to use a CI system that supports them out of the box.  There are several good options here with varying levels of Perforce integration.  In the simplest case, any user can upload a pending changelist to the CI server and have it built and tested on demand.  If the integration isn’t quite as easy as you were hoping for, you can always use the Perforce Broker to wrap up the process.

If your CI system doesn’t support pre-flight out of the box, you can use a couple of Perforce tools to help bridge the gap. Shelves are already a great tool for simple code review and promotion, and you can use shelving triggers to invoke a CI process on shelved files.  I’d recommend running this asynchronously and just notifying users when the results are in.  Or, grab a hold of Swarm and run CI as part of your review process.

Another advantage of using Swarm, is that you can get more eyeballs on changes earlier in the process. Swarm has hooks for automated deployment. This allows non-technical users (or just busy users) to click a button and see the effect of a given change. You decide what the button does. It might download an executable, fire-up a virtual machine or (like we do on the Swarm team) take you to a staging site.

For a more rigorous process, you could actually intercept any commit and make sure it runs through a CI process before it is allowed to proceed.  Just be aware that the first stage in your CI pipeline should be fast if you go down this route, as users will be waiting on it to complete.

Finally I’d like to touch on a way to handle even local builds when the project has a large volume of data and running a build can take a very long time.  (Some of our customers have projects consisting of several gigabytes of data, and running a full build can take an hour or more.)  At MERGE 2013 NetApp presented a talk about using NetApp storage devices to efficiently clone a Perforce workspace.  That not only saves data transfer time, but the template workspace can be pre-populated with build data.  That means you’re just running incremental builds as you go.  If you’re dealing with a project of that size, it makes sense to use the latest and greatest storage solutions to help you along.

How are you managing pre-flight builds?  Comment here or start a conversation in the Forums and let’s exchange some ideas!