DevOps: Tear down this Wall of Confusion

In our blog post „DevOps: No one intends to erect a Wall of Confusion“ we have described everything that can go wrong, even when you are supposedly working according to DevOps principles. Problems can manifest in different symptoms. Starting with a longer time required to bring new developments into production and thus actual added value for the customer. Right through to a Dev and an Ops team confronting each other with accusations and a system landscape that is only patched up and no longer further developed.

In this blog post, we want to describe the major levers that can be adjusted to establish a successful DevOps culture.

Divide and conquer... or perhaps not?

Well, as anyone who's had anything to do with software development knows, software doesn't just fall from the sky (at least not yet), it's developed by people, and it's with these people, of course, that we must begin.

The most important thing is communication between the people developing the software and those who need to operate it. This means that anyone who comes into contact with development and operations should, as far as possible, also be aware of all processes and problems at all times and take them into account in their work.

But then both teams have to coordinate at least daily? – Exactly! But let's remove this unnecessary organisational hurdle and make both teams one team again, so that every team member automatically goes through the same meetings and everyone has a common understanding of what the problem is and what the plan is.

If everyone is playing on the same team again, it's also a shared responsibility again that the software runs stably, and development contributes its absolutely decisive part to this.

Into the vicious cycle with workarounds

We can't do that! We can't disturb our developers with operational issues while they're implementing the next game-changer. – Uh... yes we can. Because what good is the next game-changer if it never goes into operation, or only with delays, due to other problems?

Problems that block operation and often development are referred to as “technical debt”. If technical debt is not paid off promptly by fixing the problems, this generally leads quickly to „workarounds“ being built. Workarounds increase the complexity of any software project, but also of any system landscape, as they involve specific knowledge of the system and the system suddenly no longer behaves as the user would expect. Every workaround creates new technical debt, leading to a vicious cycle that becomes increasingly difficult to break free from.

Light at the end of the DevOps tunnel

But then – a glimmer of hope. By merging the teams, the employees who were previously in the operations team have received permission and hopefully also the motivation to actively contribute to the system's code. Therefore, there are now at least a few team members who can address the operational issues from a development perspective. They have become actual DevOps engineers because they have internalised the operation and development of a system and, from now on, consider both sides. You plan, build, test, deploy, and monitor your changes, and based on the experience you've gained in the last cycle, you can re-enter the planning phase and start again.

The objective now should be for everyone on the team to be interdisciplinary and equally responsible for developing new features, fixing bugs, and also transferring the changes they have made into live operation.

If this is successful, all team members will follow the DevOps leitmotif: „You build it, you run it!“

Naturally, in this example, many points are overly dramatic, but we are sure that many developers (for Dev and Ops) have found themselves in a comparable situation. We ourselves occasionally catch ourselves acting in ways that are the opposite of this DevOps philosophy. What's important is to reflect on yourself and, if necessary, correct the odd decision.

For us, therefore, DevOps has nothing to do with any tools like CI/CD pipelines or anything similar in the first place. For us, it's about every team member developing the mindset that the features they develop are also rolled out by them, that operations are evaluated, and that the experiences can be incorporated into the next planning phase.

Supportive techniques

Unlike the development of new features, regularly deploying a new version can, of course, become extremely monotonous very quickly. Super, monotonous tasks can be excellently automated, e.g. through a lively CI/CD pipeline. This can save errors during manual rollouts and, of course, a lot of time, allowing the team to concentrate more on other areas, such as system development.
Through appropriate automation, the process within the team is standardised, and project progress becomes more transparent for all involved developers, as well as for project managers and clients. Things like a CI/CD pipeline therefore promote the DevOps cycle, but one doesn't automatically „do DevOps“ just because a CI/CD pipeline has been set up.

In summary, we'd like to offer the following tips:

• DevOps is primarily a work mindset
• The development of software and its operation are symbiotic and should not be separated disciplinarily or culturally (e.g., by two teams).
• Methods like CI/CD pipelines or functioning release management foster a DevOps culture by defining automated standards for how work is done, but they do not necessarily mean you are doing DevOps.
• Not only the development of software, but also the development of automated operations is fun

We hope that with this blog post we were able to present our view on the somewhat dated, but still relevant topic of DevOps.