10 Essential Steps to Mapping Your DevOps Journey

We look at 10 suggestions from Puppet Labs’ 2015 “State of DevOps” report for mapping out a DevOps journey and how to build a high-performing IT team.

This is where you begin to build your business case. Simply declaring “We’re doing DevOps” is not going to get people on board. Instead, you need a compelling answer to the questions: “Why? And why now?” This year’s “State of DevOps” report confirms that DevOps practices lead to better IT and organizational performance. High-performing IT departments achieve superior speed and reliability relative to lower-performing peers. The 2015 survey showed that high-performing teams deployed code 30 times more often and with 200 times shorter lead times than their peers. They achieve this velocity and frequency without compromising reliability—in fact, they improve it. High-performing teams experience 60 times fewer failures.

The big-picture case is solid, but people also want to know how DevOps affects them at an individual contributor level. Show them how it will improve their jobs and address the things they care about most. As your DevOps journey gets under way, underscore these benefits with data demonstrating early wins. It’s important to get both the dev and ops teams on board with DevOps. Faster deployments and feedback loops get to the heart of what a developer wants. Ops benefits when developers work closely with them. It’s a win-win.

So how do you begin to measure these DevOps impacts and bolster your business case? Start small with specific tasks and projects, including the cultural shift; don’t expect to sell DevOps to everyone at once. In fact, by winning over smaller groups with specific projects, you’ll create ambassadors who can help promote DevOps elsewhere in the organization, creating a multiplier effect. As you build your business case and bolster it with early wins backed by data, you should also remain mindful of potential obstacles to long-term DevOps success.

Aligning goals and incentives is an absolute must for tackling the next considerable challenge: cultural change. A significant transformation like DevOps can produce noticeable fear, especially in the absence of reassuring data. If developers think DevOps means their phones will start ringing nonstop on nights and weekends, can you blame them for a being a bit skeptical? If systems administrators believe automation will eliminate their jobs, then fear is a natural response. Communicating and celebrating DevOps successes along the way is a crucial strategy for reducing fear and continuously building the business case.

While it’s true that legacy tools and systems may pose considerable challenges as you move forward, many IT teams in the most risk-averse industries turn to DevOps because they realize it’s more expensive to maintain the status quo than to adopt new technologies and practices. The good news is that tools, unlike the broader corporate culture, fall more directly under Ops’ control. You don’t have to overhaul everything at once. It’s okay to start with one small thing, or at least one distinct thing.

Always keep a close-knit collaboration between dev and ops teams. This structure takes once-siloed development and operations functions and redeploys them as tightly woven, highly collaborative teams working side by side. This often involves considerable change from the previous way of doing things. Create a purpose-driven DevOps team. These teams typically start by addressing the things that are most painful, such as deployment automation, and if they’re successful, can evolve to providing shared services for the rest of the organization.

Contrary to what some vendors might tell you, there’s no single, one-size-fits-all DevOps tool. Rather, the most effective results come from standardizing on a tool chain that maps directly to best practices, such as version control, peer review and continuous delivery—all built on a foundation of managing infrastructure as code. The DevOps tool chain should include version control (GitHub, Mercurial, Perforce, Subversion, Team Foundation Server); configuration management (Puppet and others); continuous integration (Atlassian Bamboo, Go, Jenkins, TeamCity, Travis CI); deployment (Capistrano, MCollective); and monitoring (New Relic, SignalFx, Nagios, Splunk, AppDynamics, Loggly, Elastic).

Start small and automate things that are causing the most pain. The “DevOps” report found a strong correlation between IT performance and deployment pain. Ask your teams two questions: How painful are your deployments? What is causing the most pain? The answer to the first question will tell you how your team is performing. The answer to the second question will tell you what to prioritize.

The next move is to start standardizing processes and tools to reduce complexity. Do an audit of all your applications to understand what tools and processes are currently in place. There are two critical practices that significantly increase the reliability and stability of the system, while also improving throughput: the use of version control for all production artifacts and infrastructure as code. Standardizing the tools used for these practices across the organization further increases productivity and efficiency. When you’ve automated away pain points and standardized tools and processes, you can now expand your DevOps implementation to areas like application deployment and systems monitoring.

There may not be a single end point for DevOps, but there is an overarching goal: Become a learning organization that’s always striving to improve and deliver more value to customers. You may never be “done” with your DevOps journey, but if persistent, you will reach a point where everyone on your team works in alignment within a process of continual learning and improvement.