This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
3. - The tools of the DevOps trade: Read more in this section
Explore other sections in this guide:
The core of a successful DevOps environment requires a shift from the traditional software development model to one that can keep pace with the rapidly changing business environment. Another critical piece is getting the right tools in place to streamline the automation process and consequently avoid technical hiccups.
Peter Walsh, Agile development and DevOps trainer, talks about the beginnings of DevOps, and how to get it running properly in your IT shop. Walsh is scheduled to give a two-part workshop entitled “Building a Working DevOps Tool Chain” at LinuxCon North America 2012 in San Diego at the end of August.
We've heard the term DevOps, but where did it originate? What set of circumstances set it on its current evolutionary path?
We see DevOps as the next evolutionary step in Agile development. You can accelerate coding and testing, but if you can't field it quickly, it is not very useful. Kind of like the old "I Love Lucy" episode where she works the chocolate candy line. She can't keep up, and [the candy falls] on the floor, and she eats them. All the parts of your team need to work together to deliver to the customer.
To us, DevOps is an "OK" term but can be misleading. Some people like “continuous delivery” but that hardly rolls off the tongue nor does it sound cool. The Agile guys landed on a great term that conveys a good, self-explanatory message.
One of the interesting challenges we face with our government customers is a fear that DevOps doesn't include testing. Many folks on the commercial side — especially those doing Agile— have embraced the notion that "dev" includes coding and test — not the case with the government. Software development for the government includes a very traditional waterfall flow, usually with multiple — many! — discreet test phases. They are still trying to inspect in quality. They see the term DevOps and get very nervous that test is being cut out of the loop. It can be a very adversarial climate that is the opposite of the collaboration needed to achieve a successful DevOps flow.
Another area that gets [people] nervous with the term are the security and compliance teams, whether in Department of Defense, finance, health, etc. They equate speed with insecure. We always work to include them as part of the team so it is easier to work in their requirements in parallel.
What brought you to the DevOps table and drove you to develop a talk on DevOps tools?
We were building a complex tool-set from the ground up and very quickly ran into the congestion issue. Developers we working hard but there was nothing to show; the sys admins could immediately see a storm on the horizon. We collectively had an "ah-ha" moment and realized we needed to do it right.
Now that moment came easy and early for us because the tool we were developing was for automating provisioning, software builds and test. We knew we had to practice what we preach and "eat our own dogfood." We have developed a product called CONS3RT to empower users to do DevOps without having to figure it out from scratch. It is intended to provide a generic framework that allows users to adapt to the tools and environments they are working on.
Without going too much into the specifics of your presentation, can you tell us a few things to look for in a successful DevOps tool?
First and foremost is automation. As you assemble a tool chain to meet your needs, it is critical that each component tool support automation is some way. Otherwise you introduce break points and risk areas — places where things get stuck in queue, places where individuals can derail or break the process, places where things could possibly get skipped.
Automation also goes a long way to ensuring repeatability and consistency. Without break points, you have more control over the flow, guaranteeing greater repeatability.
The other big piece of the tool chain is people and change management — isn't that always the case? Just like with adopting Agile or any other approach, you need to have the team on board. So that means all the standard stuff — good communication, clear plans, risk-free environment, leadership, etc.
In your experience, what kind of IT shops adapt best to DevOps approach, and which tend to drag their feet? What success or failure stories have you seen?
So far we have seen the best adoption is newer technology companies with highly skilled teams and fairly narrow focuses. Flickr is always used as example for how fast they deploy new builds.
Obviously the government example stands out as a challenging environment. We have had some success but so far only in small pockets.
The biggest challenges we see are:
- the in-house skill-set required to assemble a tool chain and associated dependency on key personnel
- the single purpose nature of most tool chains (preventing reuse as much as you would like)
Adoption is slower say with financial firm X because they have multiple development projects — mainframe integration, N number of customer portals, in-house resources, regulatory interface, etc.
What's the main thing you want people to look forward to at your LinuxCon talk?
My goal for attendees is to understand:
- the various steps in the process so they can map one or more tools to each of them
- the human engineering component of it, and ideally some strategies on how to deal with them
I think attendees can look forward to a lively, interactive session. Given the time, we obviously won't code anything but there will be some hands-on activities.