Six Core Capabilities of a DevOps Practice – InApps Technology 2022

DevOps is a term that reflects what happens when seeming disparate concepts are turned into a portmanteau. Combining developers and operations into one concept creates a new dynamic that changes the way people think about IT and the role of the developer in the organization.

To think about the concept clearly, it’s important to define the most important capabilities of any DevOps environment. Our research shows there are really six that are most important to consider:

• Collaboration
• Automation
• Continuous integration
• Continuous testing
• Continuous delivery
• Continuous monitoring

Developers and operations have historically been separate organizations in IT. They have been separated due in many respects to the constraints of enterprise systems practices and the shift from waterfall to agile development processes. Before any app can be put into production it needs to be configured so it performs as expected by the user. In production, the app and the systems that support it need monitoring.  Developers may create the app, but it is up to the systems team to often manage hotspots, unusual spikes and transactions across a distributed infrastructure.

But more than ever, developers and operations need to have shared practices. Efficiency matters but the greater need is for app development. Apps needs to be designed faster, tested and deployed across mobile and web platforms.

DevOps has lots to offer in this complex new world. It offers a process that can be put into place and repeated without distracting from other work and a person’s personal life.

But it also offers impediments. “Navigating DevOps” is an ebook New Relic published that covers the six capabilities of DevOps to help companies get a grip on what they want to accomplish. These points adapted from the book can help offer some perspective on ways to approach the DevOps topic:

 1. Collaboration

Instead of pointing fingers at each other, development and IT operations work together (no, really). While the disconnect between these two groups created the impetus for its creation, DevOps extends far beyond the IT organization, because the need for collaboration extends to everyone with a stake in the delivery of software. As Laurie Wurster et al. explained in a recent Gartner report: “Successful DevOps requires business, development, QA, and operations organizations to coordinate and play significant roles at different phases of the application lifecycle.  She further said:

It may be difficult, even impossible, to eliminate silos, but collaboration is essential.

2. Automation

DevOps relies heavily on automation—and that means you need tools. Tools you build. Tools you buy. Open source tools. Proprietary tools. And those tools are not just scattered around the lab willy-nilly: DevOps relies on toolchains to automate large parts of the end-to-end software development and deployment process.

The only caveat: Because DevOps tools are so amazingly awesome, there’s a tendency to see DevOps as just a collection of tools. While it’s true that DevOps relies on tools, DevOps is much more than that.

 3. Continuous Integration

The continuous integration principle of agile development has a cultural implication for the development group. Forcing developers to integrate their work with other developers frequently—at least daily—exposes integration issues and conflicts much earlier than is the case with waterfall development. However, to achieve this benefit, developers have to communicate with each other much more frequently—something that runs counter to the image of solitary genius coders working for weeks or months on a module before they are “ready” to send it out into the world. That seed of open, frequent communication blooms in DevOps.

4. Continuous Testing

The testing piece of DevOps is easy to overlook—until you get burned. As one industry expert puts it, “The cost of quality is the cost of failure.” While continuous integration and delivery get the lion’s share of the coverage, continuous testing is quietly finding its place as an equally critical piece of DevOps.

Continuous testing is not just a QA function, in fact, it starts in the development environment. The days are over when developers could simply throw the code over the wall to QA and say, “Have at it.” In a DevOps environment, everyone is involved in testing. Developers make sure that, along with delivering error-free code, they provide test data sets. They also help test engineers configure the testing environment to be as close to the production environment as possible.

The payoff from continuous testing is well worth the effort. The test function in a DevOps environment helps developers to balance quality and speed. Using automated tools reduces the cost of testing and allows test engineers to leverage their time more effectively. Most importantly, continuous testing shortens test cycles by allowing integration testing earlier in the process.

5. Continuous Delivery

In the words of one commentator, “continuous delivery is nothing but taking this concept of continuous integration to the next step.” Instead of ending at the door of the development lab, continuous integration in DevOps extends to the entire release chain, including QA and operations. The result is that individual releases are far less complex and come out much more frequently.

The actual release frequency varies greatly depending on the company’s legacy and goals. For example, one Fortune 100 company improved its release cycle from once a year to once a quarter—a release rate that still seems glacial compared to the hundreds of releases an hour achieved by Amazon.

Exactly what gets released varies as well. In some organizations, QA and operations triage potential releases: many go directly to users, some go back to development, and a few simply are not deployed at all. Other companies—Flickr is a notable example—push everything that comes from developers out to users and count on real-time monitoring and rapid remediation to minimize the impact of the rare failure.

6. Continuous Monitoring

Given the sheer number of releases, there’s no way to implement the kind of rigorous pre-release testing that characterizes waterfall development. Therefore, in a DevOps environment, failures must be found and fixed in real time. How do you do that? A big part is continuous monitoring.

According to one pundit, the goals of continuous monitoring are to quickly determine when a service is unavailable, understand the underlying causes, and most importantly, apply these learnings to anticipate problems before they occur. In fact, some monitoring experts advocate that the definition of a service must include monitoring—they see it as integral to service delivery.

Like testing, monitoring starts in development. The same tools that monitor the production environment can be employed in development to spot performance problems before they hit production.

Feature image via Flickr Creative Commons.