Taking DevOps from experimentation to mainstream practice

DevOps as a distinct software development methodology was born 10 years ago, yet today most organizations are still at an early stage of maturity. Here’s how it often looks: IT leaders know its time to move toward DevOps, so they hire or build a dedicated team with the appropriate skills.

This team takes care of standard automation tasks – typically small deployment projects that the core IT department can’t handle or deems as lower priority. This fill-the-gap strategy seems smart, but not much is really changing in the way the company develops and releases code. The new DevOps team becomes one more silo in the organization. The DevOps movement eventually loses steam.

For DevOps to succeed, the company cannot view it as a “program” or an extension of IT.  DevOps people and practices must be integrated with all the other teams: streamlined collaboration with automation is the whole point.

It starts with committed leadership and cultural change. Of course, this is the part that organizations tend to overlook or neglect. It’s a big hairy goal. You’ve got employees with lots of experience and who are proud of their work, legacy processes and technologies that on the outside seem fine, and likely, misunderstandings about why things must change.

The CIO or Head of Engineering will need to persuasively demonstrate and communicate the need for change and benefits to employees and the business, over and again.

With the foundation of a committed leadership team working on cultural change, teams can begin working on the tactical measures leading to DevOps as a mainstream practice:

# 1 | Integrate roles and teams

The notion of a separate DevOps team must go away. Introduce DevOps engineers to the development team as daily partners in the work, including working with developers during sprints.

Too often, developers have no clue how their code works in the infrastructure nor what operations people do with the code once received.  They may also care less.

The DevOps expert can bridge the gap between developers and operations so that all parties understand the pipeline they are building. This shared understanding leads to shared respect and better decisions and outcomes. Having a shared reporting structure helps immeasurably, as well as physical proximity.

# 2 | Integrate feedback

After better awareness, comes the need to change practices.

In DevOps, automation and consistency are the undercurrents of all processes. How this plays out is that once the engineer receives a new batch of code, they talk to the developer about potential issues during deployment, such as a third-party application dependency. The developer can then make the appropriate fix then and there, to minimize downstream risk.

# 3 | Simplify tooling

Many organizations worry that putting together the proper technology infrastructure will be expensive – but in most cases it is not.

Many DevOps tools are open-source and you don’t need more than three or four applications, even if the organization is adopting a rigorous continuous deployment/continuous integration (CD/CI) process.

What often happens is somebody selects a tool which doesn’t end up covering an important use case, so people keep adding tools. Before long, you’ve got a complex infrastructure of technologies and too many data sets floating around.

The IT/Development leader’s job is to guide and control the tool selection process. Despite the marketing hype, most DevOps tools, more or less, do the same thing: automate and manage the build, test, and deployment of software. You can’t go wrong incorporating Jenkins into your toolset since most DevOps people know how to use it.

This article was contributed by Michael Burch, Cloud Architect at NetEnrich.