The Puppet community is great and we’re glad to be a part of it.  But there’s a new community to jump into – Jenkins, the leading platform for continuous integration- and a new domain to address – continuous deployment.

Since we released Stack Hammer earlier this year, we’ve been getting the same two questions over and over:

• “The validation testing in Stack Hammer (and Wham!) is really powerful. Can Stack Hammer trigger our other tests the same way?”

• “We’re deploying continuously. How can we integrate Stack Hammer’s configuration testing/validation service into a continuous process?”

We’ve taken the hint, and we’ll be adding more explicit support for continuous deployment. In fact, this will be our major product priority over the rest of this year.

Our first step is a Stack Hammer plug in for Jenkins, which we’ll be previewing at a Jenkins User Conference we’re co-sponsoring this week in NYC. The plugin lets you add Stack Hammer validation and deployment steps directly to a Jenkins project.

A typical usage scenario would be to trigger these steps using a Git hook, so that your stack is revalidated and deployed, for example, each time someone makes a commit to GitHub. Kenn will be demoing this at the conference, using Stack Hammer and Jenkins to continuously deploy and test a Jenkins stack (yes, it’s very *meta*), with the code edited directly at GitHub and the Jenkins stack running at Amazon.

The plug-in needs to call out to Stack Hammer as an external service, so we’ve added support for a RESTful API. We’ve implemented this in a generalized way, so pretty much any external application can now call Stack Hammer as a service. A number of people have asked for this, and we’ll be documenting it so anyone can use it.

A key point is that in continuous deployment scenarios Stack Hammer generally will be filling a specific gap – configuration testing – rather than providing a complete, end-to-end configuration management service.  This is a direction we want to take in any case, because we’re finding that many prospective users are relatively far along the Puppet investment curve and want to fit Stack Hammer into an existing workflow. So current and future Stack Hammer functionality will be applied to a more focused value prop – continuous configuration testing – where most organizations still have a hole.

Our next step will be to introduce a more general purpose capability to drive testing based on configuration changes. The necessary framework for test integration is substantially complete, and we’ll be doing some refactoring of the Stack Hammer UI to cleanly separate the validation, test and deployment domains. We plan to preview the complete story at the Dublin Puppet Camp in early July.

May and June will be very busy.

There are three secrets to being an extremely successful and charismatic leader. (1) Build a team that can make you look awesome. (2) Pretend to listen to that team even when you know they’re completely wrong, then overrule them. (3) Have the confidence to admit that although, with the full benefit of hindsight, you may not have been 100% correct on every little detail, you still totally nailed the big picture.

All three of those management principles were on display in the case of Geppetto. When Kenn and Henrik came up with the idea of an Eclipse-based IDE for Puppet early last year, Management politely heard them out before telling them it was one of the dumbest ideas of all time. Who would ever want to use something that? Eclipse is for old men! The kids today are all using command line, not IDEs!

As usual, the team ignored Management and did whatever they damn well pleased, working on Geppetto in secret through 15 long months of nights, weekends and vacations.

But the story turns out to have  a happy ending: Geppetto is doing really well. Unique user downloads crossed the 3,000 mark in April, and are accelerating. Many of those users probably download Geppetto and then redistribute it internally, so more could be actually using it. These are pretty decent numbers, given the size of the Puppet user community and the fact that we’ve had very little time to promote it. It may not be for every Puppet user, but those that like it seem to really like it.

And so what if Management said that an Eclipse-based IDE for Puppet was a total waste of time, and Geppetto is an Eclipse-based IDE for Puppet? From the start, Management’s vision has been that, in the future, people were going to need a lot more stuff to make things way better. And isn’t that the the key takeaway regarding Geppetto? Doesn’t it make things *way better*? Let the team sweat the details. That’s their job, not Management’s.

Geppetto 2000

Not all of us here at Cloudsmith are dry and technical. Sure, those of us working down in the trenches may be a bit “serious”. But our most creative elements, such as Kenn and Henrik, the duo behind our new Wham! service, have all the style and flair you would expect of pop stars.

They created Wham! so that you’d have no remaining excuses to not pick up your stack hammer. Just type in the name of a module from the Puppet Forge, or a GitHub repository containing some Puppet code, and click. A graph magically appears, showing you color-coded errors and dependencies!

Wham! uses the same validation and graphing services as Stack Hammer. But while the flagship service is deep, powerful and (some may say) a bit complex, Wham! is shiny, sexy and simple. But still just as useful.

So instead of wondering what’s “lurking in the bushes” (figuratively speaking) of that code you’d like to use, get it all out into the open! You’ll feel better and stack safer!

Use Wham! as a standalone service right now. And wait for us to tie it into the rest of Stack Hammer over the next few months.

Interestingly, maybe a third of the audience now had some experience with Geppetto, which showed this exponential spike in downloads last month. Kenn must have been telling people down there that Management had originally declared Geppetto a complete waste of time, because Management’s ears were burning throughout the day on Friday.

But taking off our community hat and donning the crass chapeau of commerce, what we found most interesting were the results of the early look Kenn gave at the upcoming Stack Hammer release. Granted, Kenn was only able to show it to the six or seven people he ate lunch with, but it seems they all REALLY LIKED IT and might even want to USE IT! (At least that’s what they said.) So we’re getting a good feeling.

Our next report on this topic is imminent.

First up is Atlanta, where we’re hoping to give folks an early look at our new release. Then we’re off to Edinburgh in March, followed a few days later by Stockholm, which we’re co-organizing with Puppet Labs.

New York, Chicago, D.C. and hopefully Amsterdam should follow, adding up to a year-on-year increase in our marketing activities of 250% for Puppet Camp alone.

All in all, 2011 was a pretty good year. We pivoted to a new technology/user community (Puppet); built up credibility through a substantial open source contribution (Geppetto); worked through two betas of a new service based on that community (Stack Hammer); and generally just got our act together. We even found time to get this guy to do this. Most things took a little longer than we hoped, but that always seems to be the case for us.

2012 promises to be an even better year. That’s because we’re close to washing our hands of this whole *beta thing* and getting *out there* with a real service, as in, one people would be crazy not to use and hopefully pay us for.

Cleaning up after those contractors always takes a bit longer than expected. Since we’ve already missed our ideal release date of November 11 (Nigel Tufnel Day), we’ve decided to combine the release with all sort of capabilities we’d planned for later this year. The end result should be pretty awesome.

We’ll report back with the details when we have a date.

The team assembled for Management's rousing presentation

There were actually no real surprises. We hoped to put in place the foundation for a really useful product solving really important problems. That seems to have gone as planned. Stack Hammer seems able to do pretty much everything users want to do with it.

We also knew that we didn’t exactly know what really important problems people would want to solve with our really useful product. We’re relatively new to this particular user community, so we don’t have enough direct exposure to what bothers its members day-to-day and what they like and don’t like.

So we didn’t even try to include in Beta 2 much to help the user figure out how exactly to get started, because we figured it would be a waste of time. It pretty much violates every current best practice for building applications (or building buildings, where you generally put in doors and windows at the same time as the walls), but it made sense to us at the time.

So that’s what we’re working on now. We’ll be releasing features over the next month that show you how things fit together, how to get started and make it easy to navigate around. What’s underneath won’t change very much, if at all.

Another thing we’ve held off on is aggressively promoting Stack Hammer to the community at large. If we aren’t there to help you get started, we’re concerned you’d just get irritated and leave. (That’s what we’d do, after all.) So no Stack Hammer spam until next month!

• Getting several hundred attendees to wear our ridiculous t-shirts or stick our ridiculous stickers on their notebooks.
• Getting a significant number of attendees to be photographed with their faces sticking through a ridiculous poster.
• Giving a slick Stack Hammer demo to everyone who walked by our station with only *one* bug encountered, which Kenn skillfully worked around in all subsequent demos.
• Verifying that that lots of people think Stack Hammer will be awesome (which we suspected but really didn’t know, because we hadn’t talked to two hundred potential users).

These were not isolated events. In fact, as our Creative Director explains to us, the site design, naming, t-shirts, stickers, cheap publicity stunts, etc. – everything plays a part in creating an edgy brand around an awesome product.
 
The biggest achievement was the fact that Kenn was able to give a few hundred Stack Hammer tours over three days with only one real bug discovered . What made this so amazing is that we entered testing a week late, lost almost another week due to GitHub API outages and other misfortunes and basically had three days to test and fix an almost completely new service.
 
Our developers write awesome product code!

It started innocently enough with a demo to show at PuppetConf. But somehow we ended up re-watching all the Old Spice Guy videos and decided we had to work that in. (We honestly can’t recall how it happened…Portland, Wieden+Kennedy, power tools…who knows?)  And then we were inspired to try our own hands at producing edgy, offensive material that would appeal to the sort of young people we’re likely to encounter at PuppetConf.

And before we knew it, we had probably gone too far, but printers had been paid and the presses were already humming. Having recently skimmed Dick Cheney’s memoir at Barnes & Noble, however, we did remember to build plausible deniability into the most offensive material, so we should be ok.

We’ll have pictures from PuppetConf for you next week.