In this article by Joakim Verona, the author of the book Practical DevOps, we will be introduced to DevOps.

An important part of DevOps is being able to explain to coworkers in your organization what DevOps is, and what it isn’t.

The faster you can get everyone aboard the DevOps train, the faster you can get to the part where you do the actual technical implementation!

(For more resources related to this topic, see here.)

Introducing DevOps

DevOps is, by definition, a field that spans several disciplines. It is a field that is very practical and hands-on, but at the same time, you must understand both the technical background and the non-technical cultural aspects.

The word DevOps is a combination of the words development and operation. This wordplay already serves to give us a hint of the basic nature of the idea behind DevOps. It is a practice where collaboration between different disciplines of software development is encouraged.

The DevOps movement has its roots in Agile software development principles. The Agile Manifesto was written in 2001 by a number of individuals wanting to improve the then-current status quo of system development and find new ways of working in the software development industry. The following is an excerpt from the Agile Manifesto, the now-classic text, which is available on the web at http://agilemanifesto.org/:

“Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

In light of this, DevOps can be said to relate to the first principle, “Individuals and interactions over processes and tools”.

This might be seen as a fairly obviously beneficial way to work—why do we even have to state this obvious fact? Well, if you have ever worked in any large organization, you will know that the opposite principle seems to be in operation instead. Walls between different parts of an organization tend to form easily, even in smaller organizations where at first it would appear to be impossible for such walls to form.

DevOps, then, tends to emphasize that interactions between individuals are very important, and that technology might possibly assist in making these interactions happen and tear down the walls inside organizations. This might seem counterintuitive given that the first principle favors interaction between people over tools, but the authors’ opinion is that any tool can have several effects when used. If we use the tools properly, they can facilitate all of the desired properties of an Agile workplace.

A very simple example might be the choice of systems used to report bugs. Quite often, development teams and quality assurance teams use different systems to handle tasks and bugs. This creates unnecessary friction between the teams and further separates them when they should really focus on working together instead. The operations team might in turn use a third system to handle requests for deployment to the organization’s servers.

An engineer with a DevOps mindset, on the other hand, will immediately recognize all three systems as being workflow systems with similar properties. It should be possible for everyone in the three different teams to use the same system, perhaps tweaked to generate different views for the different roles. A further benefit would be smaller maintenance costs, since three systems are replaced by one.

Another core goal of DevOps is automation and continuous delivery. Simply put, automating repetitive and tedious tasks leaves more time for human interaction, where true value can be created.

How fast is fast?

The turnaround for DevOps processes must be fast. We need to consider time to market in the larger perspective, and simply stay focused on our tasks in the smaller perspective. This line of thought is also held by the Continuous Delivery movement.

As with many things Agile, many of the ideas in DevOps and Continuous Delivery are in fact different names of the same basic concepts. There really isn’t any contention between the two concepts; DevOps and Continuous Delivery are two sides to the same coin.

DevOps engineers work on making enterprise processes faster, more efficient, and more reliable. Repetitive manual labor, which is error prone, is removed whenever possible.

It’s easy, however, to lose track of the goal when working with DevOps implementations. Doing nothing faster is of no use to anyone. Instead, we must keep track of delivering increased business value.

For instance, increased communication between roles in the organization has clear value. Your product owners might be wondering how the development process is going and are eager to have a look. In this situation, it is useful to be able to deliver incremental improvements of code to the test environments quickly and efficiently. In the test environment, involved stake holders, such as product owners and, of course, the quality assurance teams, can follow the progress of the development process.

Another way to look at it is this: If you ever feel yourself losing focus because of needless waiting, something is wrong with your processes or your tooling. If you find yourself watching videos of robots shooting balloons during compile time, your compile times are too long!

The same is true for teams idling while waiting for deploys and so on. This idling is, of course, even more expensive than that of a single individual.

While robot shooting-practice videos are fun, software development is inspiring too! We should help focus creative potential by eliminating unnecessary overhead.

The Agile wheel of wheels

There are several different cycles in Agile development, from the portfolio level through to the Scrum and Kanban cycles and down to the continuous integration cycle. The emphasis on which cadence work happens in is a bit different depending on which Agile framework you are working with. Kanban emphasizes the 24-hour cycle and is popular in operations teams. Scrum cycles can be between two to four weeks and are often used by development teams using the Scrum Agile process. Longer cycles are also common and are called program increments, which span several Scrum Sprint cycles, in Scaled Agile Framework.

The Agile wheel of wheels

DevOps must be able to support all these cycles. This is quite natural given the central theme of DevOps: cooperation between disciplines in an Agile organization.

The most obvious and measurably concrete benefits of DevOps occur in the shorter cycles, which in turn make the longer cycles more efficient. Take care of the pennies, and the pounds will take care of themselves, as the old adage goes.

Here are some examples of when DevOps can benefit Agile cycles:

• Deployment systems, maintained by DevOps engineers, make the deliveries at the end of Scrum cycles faster and more efficient. These can happen with a periodicity of 2 to 4 weeks.
  

  In organizations where deployments are done mostly by hand, the time to deploy can be several days. Organizations who have these inefficient deployment processes will benefit greatly from a DevOps mindset.

• The Kanban cycle is twenty-four hours, and it’s therefore obvious that the deployment cycle needs to be much faster than that if we are to succeed with Kanban.
  

  A well-designed DevOps Continuous Delivery pipeline can deploy code from being committed to the code repository to production in the order of minutes, depending on the size of the change.

Summary

This article presented a brief overview of the background of the DevOps movement. We discussed the history of DevOps and its roots in development and operations as well as in the Agile movement.

Resources for Article:

Further resources on this subject:

• Command Line Tools for DevOps [article]
• What is continuous delivery and DevOps? [article]
• Continuous Delivery and DevOps FAQs [article]