We use Perforce at Splunk, and it’s worked out pretty well for us. I’m a CVS admin at heart, and I know there’s some SVN sentiment, but p4 gives us a nice mix of atomic commits, attractive GUI and command-line tools, and someone to call for help if it ever completely eats itself.

Over time I’ve compiled a small library of scripts for various p4 functions that have been written time and again at different sites…mergetool is one of them. This little tool accepts a merge target (”yours” in p4-speak) and projectile (”theirs” in p4), labels both, performs an integrate, and performs a “safe” resolve -as. It logs any failures for you to resolve by hand, or submits the change set if the resolve completes successfully. It does this with a bunch of logging in a well-organized, date-stamped directory suitable for archiving (or splunking).

Splunk runs on a lot of platforms for a relatively young product and that number is always increasing. The day I started, there were packages for Intel and PowerPC Macintoshes, i686 Linux, Solaris 8 on Sparc, and FreeBSD on x86, all created with BitRock InstallBuilder, run from a simple shell script, usually by Erik. There really wasn’t much control over what went into the installer — if a file was in the installer prep directory and the shell script didn’t know to delete it, out it went.

By the time 2.1 was on its way, we’d decided to switch to native packages, and our list of platforms had expanded to include Solaris on Intel, with several more on the horizon. We also wanted to provide the “rail tarball” distribution we continue to support, in part so that QA could get started before the packaging automation was complete.

Hi! My name is Kim, and I’m the release engineer here at Splunk.

Thanks to my acquisition-happy former employer, Symantec, I’ve seen a variety of startup approaches to release engineering. Most frequently it seems some senior developer has a bug up you-know-where about how the build system should work, and some poor junior developer or sysadmin type person dutifully does the drudge work (usually by hand). At other sites, some very diligent and detail-oriented person creates and executes a process with a great deal of record-keeping and attention to detail but often not a lot of automation. Consistency across different build platforms usually isn’t a strong point.

Here at Splunk, things are a bit different. I called myself the plumber in the title of this post because that’s how I see my job: I create and maintain the plumbing that produces consistent, reproducible Splunk builds across all of our platforms, with as much visibility as I can muster. I see my contribution more as enforcing process through tools — ideally, tools that enable process in a way that is more convenient for everyone than “doing it wrong” — rather than personally pushing all the buttons and scribbling in all the logbooks. And I’ve had the good fortune to come into a culture that encourages this approach.