Release automation is a hot topic.  This is pretty exciting to witness since I have worked in the industry for a long time and crafted quite a few deployment solutions by hand.  However, there may be too much focus on release automation and not enough on release management holistically.  Pushing bits to servers with a small amount of process management around it is where most release automation tools stop.

Process management, visualization and traceability are all critical, especially as the number of releases increases.  A release management solution, of which release automation is one component, must also have a concept of what a release is.  A release is more than just a collection of builds.  It includes change requests, scheduling, approvals and many other things.

Trying to add the concept of a release on top of a release automation solution that has no concept of release or a simplistic version of release is a lot of work.  Furthermore, having to roll your own frequently results in auditability, traceability and visualization capabilities becoming more unwieldy, losing some of the value that a solution provides.

Without the right checks and balances, release automation provides an extremely effective vehicle for potentially releasing the wrong thing to production efficiently. You can talk to me more about this at the upcoming Velocity Conference from June 18-20 in Santa Clara, CA.  I’ll be in the Serena booth.  Register for the event, if you haven’t already!

Last week I was in Austin attending my second DevOpsDays event of the year and it had a very different feel to DevOpsDays London.  It was the biggest DevOpsDays event yet with over 300 attendees and a reasonable amount of sponsors, Serena being one of them.

DevOpsDays Austin focused very much on culture, much to the frustration of some but I believe it is the right choice.  Unless you are fortunate enough to be in an environment that has a culture perfectly suited to DevOps, then focusing on technology alone will probably end in disappointment.

My co-workers who attended DevOpsDays Austin last year tell me that there were more staff from larger enterprises attending this year, which tracks with the general uptake of DevOps in the enterprise.  While DevOps is slowly gaining traction in the enterprise, I certainly see a lot of interest in tools to help bring DevOps to the enterprise.  Tackling culture at an enterprise scale is something of particular interest to me and something that I continue to think about.  There is no easy answer to cultural change at an enterprise scale, but it is great to see discussions in that area at DevOpsDays events.

Patrick Debois attended and gave a presentation on the future of DevOps. He even included the definition of a meme in his session and the description was quite surprising.  Patrick always delivers great sessions and didn’t disappoint with this one.

The Ignite talks and Open Spaces were thought-provoking and full of useful information.  A particularly interesting session was on monitoring.  Jenny Yang and Toufic Boubez of Metafor Software facilitated this discussion, which was lively and informative.  You can read Toufic’s blog post on the subject.

On the second day I presented an Ignite session. Let me tell you, they are much harder to prepare for and do than a regular speaking slot.  My session on “DevOps when you can’t hire the A-Team” focused on breaking out of what I call the DevOps bubble and how to leverage open source and commercial software to achieve DevOps success.

Patrick is posting videos of the event to vimeo.

Finally, thanks to the folks at Puppet Labs for getting me to participate in their 3PM push-up session!  No photos were taken that I know of, and in all honesty, I’m okay with that!

I’m looking forward to DevOpsDays Mountain View. Hope to see you there.

Last week I was able to get the most out of my trip to Austin by attending Puppet Camp and then DevOpsDays.  Puppet Camp was a high quality event with great sessions.  The content was quite varied and really resonated with me.  I’ve noticed that the Puppet community is undergoing phenomenal growth and I’m impressed with the level of community engagement.  Initiatives such as ask.puppetlabs.com and Puppet Forge make community involvement easier than ever.  A couple of highlights from the event…

@GrandmaHenri, a technical writer at Puppet Labs, presented a session on how to document modules on the Puppet Forge.  This should keep the quality of submissions to Puppet Forge high and help people find the appropriate modules to use.

Adrian Thebo did a session on “Writing and Sharing Great Modules on the Puppet Forge” and provided good programming advice for all of the Puppet users in the room with or without a programming background.  Acronyms like MDD (Mistake Driven Development) got a lot of sheepish grins and people readily admitted to testing Puppet code in production! I think everyone came away with ideas on how to improve what they were doing.

There were many other sessions that were just as excellent and a cut above what I’m used to seeing at these types of events.  I’m looking forward to PuppetConf in August!

A big thank you to Dawn Foster (@geekygirldawn) for helping to organize an amazing event and for helping to build an awesome community.  I hope to see everyone I met at Puppet Camp at PuppetConf in August.

I just got back from attending a few back-to-back events.  One of which was ChefConf 2013. It was my first ChefConf and it was a really high energy event with a wide variety of speakers and attendees.  I chose to focus on the sessions covering culture, but there were many great sessions.

The first memorable session was “Scaling systems configuration at Facebook,” presented by Phil Dibowitz from Facebook.  A larger-than-life rock and roll guy if ever I saw one, Phil did an awesome session on why Chef was the appropriate tool for use at Facebook.  I think Phil probably made Chef support staff cringe when he discussed “tweaking” the Chef libraries to meet his needs, but he did add a disclaimer that tweaking probably shouldn’t be done.

Glenn O’Donnell of Forrester Research presented what I would call a “feel good” session which described how important the skills of everyone at ChefConf are as the industry moves forward.  Infrastructure as code is no longer a nice to have but a competitive advantage that we need to stay on top of.

Disney presented a highly polished, extremely interesting session on how Chef is used at Disney.  One session highlighted potential problems with enterprises using open source solutions.  A company had made several Chef Cookbooks and had not given any back to the community.  Comments voicing frustration quickly erupted on Twitter.

The stats on Chef community growth were truly impressive; it has more than doubled in the past 12 months.  You can read more about the momentum that Chef currently has on the Opscode Blog.

Finally, one thing was mentioned over and over and over again at most of the sessions I attended — The Phoenix Project by Gene Kim.  Characters Eric, Brent, and Bill were referenced as if they were personal acquaintances of everyone.  I suspect many people will also purchase and read The Goal, as it inspired Gene.  I know I will.

I can’t wait for the next ChefConf or Chef meet-up.  Hope to see you there!

I was inspired to write this article when I kept seeing organizations do exactly the opposite of what they should be doing to develop and deliver applications efficiently.  Essentially, they weren’t practicing DevOps principles that would provide value to customers faster and more reliably.  Check out the list of Eight Mistakes that Prevent DevOps Success, published on CM Crossroads, and make sure you haven’t overlooked any.  As always, I welcome any comments!

DevOps is about flawless execution, which is what comes to mind when I think of Ninjas.  DevOps Angle just published my article, “Secrets of a DevOps Ninja: Four Techniques to Overcome Deployment Roadblocks.”  It outlines ways to overcome deployment roadblocks.  The key takeaway is that it is extremely important to understand the processes used for deployments.

Assuming your basic processes are sound, should they be implemented as is or adapted to be even more effective when used as part of an automated process?  This brings me to a fifth technique for a DevOps Ninja that I didn’t mention in the article: continually improve your processes.  Being able to measure the effectiveness of your process is key.  Decide on the KPIs, measure them and then continually seek to improve what you are doing and how you are doing it.

Read “Secrets of a DevOps Ninja” and let me know about your experiences by writing a comment below.

I recently attended DevOps Days in London.  It was an amazing event with lots of great discussions and presentations.  Some of the solutions and ideas presented were extremely creative. I spent time mingling with people who, undoubtedly, really know what they are doing.

On Saturday morning I had the pleasure of meeting Gene Kim, renowned DevOps researcher and author, and John Clapham, development lead for Nokia.  Over breakfast we discussed the current state of DevOps and what could be done to help speed up DevOps adoption.  My opinion is that while we have practitioner buy in, practitioners aren’t the best people to present strategic initiatives to business leaders.

The Phoenix Project, which just happens to be written by Gene, does a really good job of telling the story of how IT affects business outcomes and why DevOps is important.  The story is told through the eyes of management and covers interactions between IT and many groups in the organization.  No matter whether you are a hardcore techie, senior management or somewhere in between you will probably experience many “Aha!” moments and just as many moments that will bring back painful memories.

Based on our conversation, Gene decided to present a session on how technologists can better sell DevOps to management.  The slides from the session can be found on slideshare.net.  See also Gene’s blog post “The Construction Of ‘The Phoenix Project:’ Using The Downward Spiral To Better Sell DevOps.”

So, what are the next steps?  To bring DevOps to a wider audience, there needs to be a suite of tools that are easy to use and integrate.  The skill set required to chain together various tools is immense, and frankly sometimes the ingenuity shown is not something that will or should scale to the larger market.

At Serena we are making technology to support DevOps within companies more accessible, without needing an army of consultants or gurus just to achieve the basics and keep systems up and running.

Stay tuned for future articles on how to integrate commonly used tools into processes managed by Serena solutions.

There is a term that has been floating around the internet in the past year or so which illustrates a profound change in how we need to think about applications and how they are released.

That word is “Appification”.

Think about how you use apps on your smartphone.  App updates don’t come on regular release schedules; they come when they are needed. The driver could be a fix for something that is broken or it could be in response to having fewer downloads of an app and pushing out new functionality that has been kept back, just waiting to go until App sales needed a boost.

This process is wonderfully convenient for both the vendor and users. Updates come frequently and we accept the updates without hesitation, as the changes are usually incremental and therefore, considered safe and not worth further consideration.

How does Appification relate to enterprise applications?  For better or worse, as a society we want instant gratification.  We don’t want to wait. And the way apps are delivered has proven to us that software can be delivered easily in incremental amounts.  Customers are no longer willing to accept hosted solutions that are delivered at a set schedule of weeks or months.  Missing the release train is no longer an option.  Customers want hosted applications to be updated in the same manner as Apps on their smartphones.

At Serena we think of Continuous Delivery as a superset of Continuous Integration (CI), Continuous Testing (CT) and Continuous Deployment.  Changes that are automatically propagated to all environments, except for production environments, are referred to as Continuous Deployment.  The diagram below illustrates an example of Continuous Deployment.  Deployments are approved automatically if success criteria are met for DEV, TEST and INTEG.  To deliver code to UAT, STAGING or PROD, manual approvals and scheduling is required.

 

In order to achieve what we refer to as Continuous Delivery, simply remove the manual approval or scheduling and have successful changes propagate all the way through to production automatically, assuming all release criteria are met for each stage.

This is why the terms Continuous Delivery and Continuous Deployment are used interchangeably. The only real difference between the two is where you decide to put on the brakes for automated delivery to an environment.

Embracing the impact of Appification and applying it to your enterprise applications will give you a competitive advantage over your competition, enabling you to release value to your customers faster.

Join us for the next DevOps Drive-In webcast on March 19 at 8:00 a.m. PST.  Glenn O’Donnell of Forrester Research will talk about 5 Simple Change and Release Management improvements that you can make.  Why wait years for improvements when you can have them now?  Register for the webcast!