DevOps Basics (1/2): Advantages & Best Practices

---

---

Remind me again: what is DevOps?

Shortly after you first start learning about DevOps, it becomes clear that there is no single clear definition of the term. It is not, as is often assumed, a tool or a programming language. Rather, to put it in a nutshell, it is a collection of procedures, practices, and methods to deliver new software features faster.

The aim is therefore to shorten the time from the idea phase to publication in order to create satisfied customers. In addition, DevOps is always a question of having the right mindset, since the boundaries between the departments are broken down in favor of creating cross-functional teams. This means that, for example, the teams for development, operation, and quality assurance are brought together and act as one unit.

It used to be common practice that an entire application would be developed, quality assurance would test the finished product, and then it would be put into productive operation by IT administrators. With DevOps, individual components of this application are developed, tested, and put into operation. The obtained feedback immediately flows back into the development process and can be used to conduct additional development with a stronger focus on the customer’s wishes. The term DevOps is therefore a portmanteau of the terms Development and Operations.

Where to start?

Experience has shown that it is not easy to implement new working methods at a company that is fundamentally changing the terms of how its employees collaborate with each other on a daily basis. It is therefore important to take your time and not try to do everything at once. In addition, employees must be open to new work and thinking processes. Otherwise, the initial euphoria will quickly fizzle out. During the first step, it is essential to identify the processes that offer the greatest possible potential for improvement and to begin with a DevOps transformation in these areas in particular. To identify these processes, you should be able to answer the following questions:

• How long does it take for us to get a newly developed feature to the customer?
• What are the areas where teams are usually forced to wait for the work product from another department?
• Which manual work processes are the most time-consuming?
• Which manual work processes are particularly prone to error?

After you have identified suitable starting points, the next steps depend on the problem that has been identified:

• If there are problems in the area of quality assurance, it makes sense to start with test automation as a first step in order to minimize errors and save time.
• If there are problems in the area of software delivery and deployment, the first step should be to come up with a solution for continuous delivery and a suitable DevOps toolchain.
• Are your employees/colleagues unwilling to adopt new working methods? We recommend that you conduct a joint workshop to work out what advantages DevOps offers in your daily work and why it should be used.

What are the advantages of DevOps?

Of course, you shouldn’t just implement DevOps because it’s the hip thing to do. It is important that all of the people involved understand exactly what improvements need to be achieved.

Better cooperation

By actively breaking down departmental boundaries and assembling cross-functional teams, you promote stronger bonds between your employees. This leads to more frequent exchanges and to the development of a team that works together on the big-picture. Knowledge no longer remains siloed with experts working in isolation. Rather, it is distributed among multiple people on the team. Work processes no longer stand still forever because everyone is waiting on a person who is currently unavailable. There is no waiting for individual “knowledge silos,” and work processes can run more smoothly.

Increased flexibility

One of the most important features of DevOps is the division of the overall product into smaller subproducts. This type of division can be achieved, for example, through the use of microservices. These can be edited, exchanged, configured, and published much faster. By using these microservices, the company can react much more agilely to changes, customer requests, and feedback.

Simple scalability

Automation is at the core of a DevOps transformation so that you can stay in control even with rapidly growing applications and platforms. By automating testing and deployment, you can eliminate the biggest time wasters early on, since effort no longer increases exponentially with the size of your applications. As the scope of functions expands, there are more and more software dependencies and interactions that need to be checked manually. As a result, the time required for testing is growing at an ever-increasing rate. If you automate this process, you’ll have a lot more time to improve your product and save not only your nerves, but also money!

In addition: The earlier a bug is discovered, the cheaper it is to fix it, since the branches and dependencies with other features are much less pronounced at this stage.

High reliability

The minimization of manual work processes by maximizing automation reduces the error rate. This reduces the probability of failure of your productive applications, thereby increasing the level of satisfaction of your customers. Thanks to an effective DevOps toolchain, you always have an executable copy of your software, since the versions are backed up and can be restored. Furthermore, you will be automatically notified of failed tests or changes so that you can then take immediate action.

Increased speed

The basic idea of DevOps is that you can save time at every stage of software development in order to use it sensibly on the things that add value. Regardless of which part of the process we look at, from development to quality assurance and rolling out changes, DevOps lets you do it faster than would otherwise be the case! Manual processes are particularly time-consuming, since they are often very prone to error. Examples of this are transfers between separate departments or the manual provision of new features. All of these things can be measurably improved through the use of DevOps.

More feedback

Under “traditional project management,” it is often the case that customer feedback is directed to the support department or the service desk, from where it is never shared again. As a result, the development teams do not receive any input as to where there is still room for improvement.

In contrast, the gathering and distribution of feedback is one of the most important goals of DevOps. After all, you already probably do everything you can to ensure that new features reach the customer quickly and that you receive feedback on them. The customer’s opinion is then redirected back to the team and shapes the way forward for the project. This proximity to the customer means that much better products are developed because they are precisely in line with customer requirements. This increases customer satisfaction and customer loyalty over the long term. In addition, you are able to save (financial) resources because all of the adjustments that are made to products are tailored to meet the requirements of the market. This avoids making unnecessary adjustments based on mere assumptions.

What is not required for DevOps

As you can see, DevOps offers you and your company many advantages for improving software development and customer proximity over the long term. In order to avoid any misunderstandings when implementing DevOps, we would like to address a few things that are not important for your DevOps transformation:

There is no need to change your entire organization

If you want to use DevOps methods, there is no need to hire new staff or create departments. You should devote your resources to training existing staff to work across the boundaries of different departments.

All teams who are actively involved in the software development and deployment process should be able to use the tools they need effectively. This includes, for example, the configuration of tools for managing and monitoring your infrastructure. It is probably the case that developers (up until now) had fewer points of contact with these types of tools. In addition, employees should be trained to understand and how to use continuous integration and continuous development. This leads us directly to our next point:

Tools alone are not enough.

There are countless tools and toolchains that should be used to support and enable DevOps. However, these should only be used to support the goal of successfully implementing DevOps. The first step is to understand why these tools are being used and what needs to be achieved with them.

It is important that your employees understand the methodology:

• Why do we need continuous integration/continuous development?
• Why do we want to change something?
• Why should we do anything differently than before?
• What is the big goal that we want to achieve with DevOps?

It is only once your employees can answer these questions that you should start thinking about the tools you want to use to implement your DevOps strategy.

DevOps is not the same thing as automation

Automation plays an important role in the implementation of DevOps processes. However, it is not the main criterion of DevOps. At the center of effective DevOps is facilitating networking between employees and achieving a better connection with the customers who ultimately use the software. Automation is used as the means of delivering a better experience to these customers and giving them the changes they want faster. By automating business processes, the development process picks up speed and sources of human error are minimized. Automation alone is not enough. After all, just because my software contains fewer bugs does not mean that my departments are able to work across functions or that customer feedback is used more effectively.

Conclusion

At the beginning of a DevOps journey, the focus should be particularly on the topics of corporate culture, cross-functional teams, and the mindset of employees. Everyone involved should understand exactly what is to be achieved using DevOps and which individual steps need to be taken to reach the desired goal.

In addition, it is important not to implement everything at once. Rather, you should identify inefficient processes to improve in the first step. Successes should be communicated in a particularly transparent manner in order to further increase acceptance for the change process.

While in this part of our DevOps series we have focused on the cultural aspects of the transformation process, in the second part we will concentrate on the individual phases of a DevOps-driven project. We will show you how you can support this phase by using a suitable toolchain.

---

---