Buzzword alert! The term DevOps, which includes components of software development and operations, is being bandied about wherever you look: You'll find abundant references to DevOps in blogs, books, articles, training courses, and software.

This new style of cooperation between developers and admins was released on an unsuspecting audience by John Allspaw and Paul Hammond (among others) at California's Velocity Conference 2009. Their slides [1] describe how techies from the photo community Flickr achieve 10 or more deploys per day.

The approach described by Allspaw and Hammond is now part of everyday business in other Internet companies. "My impression is that you can no longer survive economically as a company with the old work models," said Schlomo Schapiro, System Architect with Immobilienscout24, in an interview with the author.

IT professionals describe themselves as DevOps specialists with increasing frequency, and some companies even have DevOps departments. The "2014 State of DevOps Report" [2] indicates that 31 percent of more than 9,000 respondents see their position as a DevOps Engineer. According to the survey, 16 percent work in a DevOps department.

The report, with 46 percent of respondents from the United States and 25 percent from Europe, was commissioned by Puppet Labs, IT Revolution Press, and ThoughtWorks. Keep in mind that these companies offer software, publications, and services related to DevOps, which means the way this work method is described is likely to be more positive.

My analysis of these self-assessments showed the following: Departments with above average performance use DevOps techniques. The deployment frequency, the time required for changes, and the mean time to recover are used as the metrics for determining the IT department's performance in the case study. This correlation might make you curious as to what DevOps followers do differently.

DevOps Principles

The DevOps principles are still basically those described in 2009 (see the "DevOps Rules" box). The key here is closer cooperation between developers and admins, usually in collaborative, product-specific teams. No longer are developers solely responsible for new software features and admins for reliable and efficient IT operations (Figure 1) – they collaborate on all of these goals.

Figure 1: The DevOps philosophy abolishes the traditional boundaries between development and operations (© J. Allspaw and P. Hammond 2009).

A YouTube video from Rackspace offers a succinct introduction to DevOps [3]. The short film explains that DevOps focuses on the deployment of small features for production systems, as the agile camp has recommended for some time. The idea is that these small features can be easily tested and rolled out without major interventions in the infrastructure.

Against Reform Gridlock

This policy of small but frequent steps keeps internal users or customers from having to wait too long for new features, and it reduces the time to market. At the same time, the procedure ensures that the development and operating system environments do not evolve separately.

According to the 2014 DevOps study, successful departments install new code on production systems 30 times more often than their less successful competitors. To progress smoothly, more actions are needed. All code must be managed with a version control system, which allows the team to roll back changes in case of problems. Continuous delivery and automatic building of the software from the latest sources prevents waiting times.

The stakeholders also integrate tests into this process that also run automatically in the course of a build, after each code change, to ensure the quality. Continuous-integration software, such as Jenkins [4] or the Travis CI service [5], helps the followers of DevOps.

Also, more than just the source code of the applications is version controlled. The infrastructure is increasingly being implemented in the form of software. All code that admins write for operations must thus also pass through Git or Subversion. This improves the mean time to recovery for infrastructure problems, because admins can quickly roll out an older version.

To distribute the configuration, your best bet is an automation system, such as Chef [6] or Puppet [7]. Monitoring software also ensures that admins discover errors at an early stage and can take preventive action before major failures occur.

Metrics

DevOps practitioners also apply metrics that reflect the work processes: How long does it take for a new feature to reach operational status? How many tickets are open and how quickly is the service desk processing them? Does the IT department comply with service-level agreements with customers and with internal operating agreements? A company needs such performance indicators to determine whether it benefits from newly introduced methods.

However, just correlating DevOps methodology and performance, as in the 2014 study, is not likely to convince decision makers; practitioners must provide proof individually. Additionally, some departments publish the metrics – for example, on a display in the office or the cafeteria. Whether these figures serve to motivate or intimidate depends on the general atmosphere at work, I suppose.