Whether at conferences or in articles, the term DevOps is currently the subject of lively discussions in the IT world. This interest is understandable, because numerous IT departments are looking for ways to free their companies from the existing mixture of delayed projects, questionable product quality and missed delivery dates.

However, despite all the enthusiasm, there is often a suspicion that not everyone has the same understanding of the term DevOps. This fear increases when CTOs and vendors claim to provide DevOps services or offer tools for them. Against this background, it makes sense to bring together and compare the different, and sometimes ambiguous, interpretations of DevOps.

What is DevOps – really?

By definition, DevOps is a set of software development practices that combine software development (Dev) and information-technology operations (Ops) to shorten the systems-development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives (https://en.wikipedia.org/wiki/DevOps). In practice, DevOps is a collaborative approach to organisational and process improvement in the areas of development and operations. With a background of finding new methods to increase agility, the term was used for the first time at a conference in Belgium in 2009. Since then, it has been one of the most discussed topics when it comes to the question of the best way of working. Many large companies are now pursuing DevOps strategies.

What DevOps isn’t? DevOps is not a methodology or a process, or a particular bunch of tools or technologies. In fact, DevOps can’t even be clearly assigned to development and operations. DevOps is also not a software-as-a-service application, even though many companies that successfully use DevOps come from this area.

Instead, DevOps is commonly understood as part of the corporate culture with certain principles that a company strives for and embraces in the long term. Supporters of this culture value cooperation, experimentation and a willingness to learn. All those involved in a DevOps culture focus on one goal throughout the entire software delivery lifecycle. Not just in development and operation but also the rapid implementation of stable, high-quality software, from inception to delivery to the customer or user.

Although not mandatory, the automation of software development, testing and deployment through Continuous Delivery (CD) is a recognised k ey factor for DevOps. Automation enables faster software implementation and ensures that solutions have the required quality, security and stability.

Defining DevOps

In simplified terms, DevOps focuses on bringing together all participants in the software development cycle at three levels: People, Processes and Tools.

DevOps can be defined and described in terms of very different models, all of which are correct in their own way and can lead to a deeper understanding and a seamless introduction. A good example can be found in ‘Three Ways of DevOps’ in Gene Kim’s book ‘The Phoenix Project’. The three ways describe intersections between systematic thinking, reinforcement of feedback loops, continued experimentation and learning at its core.

Another model is an acronym called C.A.L.M.S. According to DevOps pioneer John Willis, the five basic principles of C.A.L.M.S. are needed to establish a DevOps culture in the company according to the motto, “Keep C.A.L.M.S. and carry on”:

• Culture describes a safe environment for innovation and productivity. To create this, the boundaries of the individual areas must be broken. Separated groups of developers and operators each pursuing their own goals will no longer exist.
• Automation refers to the conviction that optimisation takes place through automation. Process automation creates consistency, saves time and avoids errors.
• Lean means avoiding waste and still achieving the desired results. Process optimisation must be seen holistically, and transparency is required for this.
• Measurement defines uniform evaluation criteria that must be created. With these, a continuous improvement of the processes is possible.
• Sharing serves as the basis for joint communication. This includes the willingness to share knowledge and to learn from each other, as well as the proactive sharing of knowledge.

These five principles form the basis for more efficient cooperation and better quality product. DevOps itself is more than a tool and simple automation. All the above building blocks for DevOps are equally important for a successful DevOps implementation. but at the core of DevOps are the people and the way they collaborate with others.

Establish DevOps as culture

Developing towards DevOps means that a cultural change usually needs to take place. Teams in development and IT operations work together to deliver mutual value throughout the entire lifecycle of the product.

With Continuous Delivery as its key factor, DevOps creates previously unknown transparency. A build monitor can be used, for example; to show the current state of the software. This can be done very granularly, i.e. each individual step (build, unit test, integration test, acceptance test, metrics, deployment on target system, etc.) is directly visible on such a monitor at any time. Once DevOps is established, not only can the state of the software be visualised, but the state of the infrastructure is also transparent. Monitoring not only gives feedback to the Ops team on their computers but is also available to developers in the same way, making the entire team feel responsible for the software. Regardless of whether the server monitoring is reporting problems, or a unit test fails, or unexpected errors are logged in the application logs, the team immediately recognises that there is a problem with the application and takes care of it – in line with the principle of collective ownership.

It is important that the movement toward DevOps is supported at the management level because it requires the dismantling of functional silos, an initial investment in hardware and software for automation, the changing of work environments and the recognition that cultural change takes time and cannot simply be introduced into the company overnight. The way in which software is developed and operated is changing noticeably, but the advantages are obvious and are usually already demanded by management: Shorter time to market, stress-free regular releases, higher quality, transparency and high-performance teams – what more could you want?