DevOps Tutorial: How to Put DevOps Theory into Practice

For nearly a decade, DevOps has been the talk of the town--or, at least, the talk of the IT industry. Everywhere you go, you hear analysts singing the virtues of DevOps as a better, faster, more secure and less costly approach to building and deploying software. Those arguments are persuasive. In most respects, it’s easy to understand the benefits of DevOps. But there remains one big problem with DevOps in many organizations today: putting DevOps theory into practice. It’s easy to talk about DevOps at a high, abstract level. It’s much harder to figure out how you operationalize DevOps, or translate DevOps principles into actual on-the-ground practices. That’s likely one reason why companies tend to report slow progress in achieving DevOps.

If that’s a conundrum you face, keep reading for real-world tips on actually doing DevOps.

DevOps at a High Level

Before delving into strategies for putting DevOps into practice, we have to start by identifying which goals DevOps is supposed to help you achieve in theory.

Different folks define DevOps in different ways, but most discussions center on a few key principles:

You need not be a professional IT analyst to understand how these goals can improve software from the perspective of both the people who create it and the people who use it.

Putting DevOps into Practice

But, again, implementing specific processes and tools that enable the goals identified above is harder. Unlike many other IT concepts, such as “the cloud” or “automated testing,” doing DevOps isn’t as simple as merely adopting a new kind of infrastructure or a new kind of tool. Nor is it as easy as hiring the right kind of staff, although some companies mistakenly think that this is all they have to do, which is why “DevOps engineer” has become such a popular job title.

Instead, putting DevOps into practice requires reconfiguring the entire software-delivery process, and it typically involves adopting a variety of new tools--as well as using existing tools in new ways.

With that challenge in mind, here are some practical tips for operationalizing DevOps.

1. Identify the tools you need.

Operationalizing DevOps should start by figuring out which tools you need to do DevOps. While there is no specific set of tools required to achieve the goals associated with DevOps, you’ll typically want the following:

Other possible types of tools to consider include:

2. Identify your infrastructure.

In addition to implementing the right tools for DevOps, you’ll need to determine which type of infrastructure you’ll use those tools in conjunction with. Consider the following options (which are overlapping to a certain extent):

3. Reorganize (or expand) your team.

As noted above, “DevOps engineer” is now a thing, and you can find plenty of qualified IT professionals who were trained specifically in DevOps practices. Adding these folks to your team is one way to help operationalize DevOps.

However, you don't need to hire a slew of new engineers or rewrite all of your job titles. You can also reorganize your IT existing team. If it’s currently broken into different groups, with developers isolated from IT Ops personnel, you’ll want to break down those barriers. That doesn’t necessarily mean having developers start working in the IT Ops department and vice versa, but it does mean building effective communication channels between the different teams, including by using the types of communication tools described above.

You might also consider strategies such as having some developers spend part of their time each week in the IT Ops department, and vice versa, or setting up recurring meetings where developers talk to IT Ops.

Ideally, you won’t stop there. Including other members of the IT organization, such as software quality engineers and security experts, in the communication channels you build will reinforce DevOps best practices and enable maximum visibility into IT operations.

You can hire DevOps engineers, too, but my general recommendation is to think of them as guides who can help facilitate communication between your existing IT teams, not replace them.

4. Implement processes to act on feedback.

Continuous communications between IT teams is not enough on its own to enable the level of continuous improvement that DevOps prioritizes. You should also take care to implement specific processes that ensure that your teams act upon the information they share with each other.

This could take the form of weekly or monthly meetings where different groups come together to discuss problems they have observed (such as a feature IT Ops has noticed that continually causes performance problems in production) and develop plans for fixing them (such as how developers will write new code to fix the performance problem just described).

Ideally, your team will also work on a daily basis to take feedback into account and make continuous improvements. But having a specific process in place to make sure that action is taken in response to data collected by different teams ensures that you actually achieve the continuous-feedback loop that DevOps prioritizes.

Conclusion

It’s easy to talk about DevOps in the abstract. It’s much harder to “do DevOps” in practice. But with the right tools, infrastructure, people and processes, implementing DevOps is quite feasible.