Basics of DevOps : Part 1

Modern companies in today’s world depend on the use of reliable software. This provides an interface to solving everyday problems and therefore contributes significantly to the success of the company. Therefore, the perfect interaction of software and hardware must be given. In order to achieve this, the development and the operation must cooperate early in the development process of new software. Often, however, the two departments tend to work against each other, slowing down the entire development process as well as providing the new software. This often costs the company a lot of time and money and can lead to the company losing the advantage over a competitor. In addition, quality assurance is already the focus during development. Therefore, these three areas need to work together from the beginning. This will provide the required agility and stability of the new software, and through continuous cooperation with the operation and quality assurance, the software can be published more quickly after completion. This new kind of software development is called DevOps and represents the interplay of development, quality assurance and operation. Therefore, certain processes in the company must be implemented with the help of teams in order to be able to use DevOps successfully in their own company. Therefore, these three areas need to work together from the beginning. This will provide the required agility and stability of the new software, and through continuous cooperation with the operation and quality assurance, the software can be published more quickly after completion. This new kind of software development is called DevOps and represents the interplay of development, quality assurance and operation. Therefore, certain processes in the company must be implemented with the help of teams in order to be able to use DevOps successfully in their own company. Therefore, these three areas need to work together from the beginning. This will provide the required agility and stability of the new software, and through continuous cooperation with the operation and quality assurance, the software can be published more quickly after completion. This new kind of software development is called DevOps and represents the interplay of development, quality assurance and operation. Therefore, certain processes in the company must be implemented with the help of teams in order to be able to use DevOps successfully in their own company.

The purpose of this article is to introduce the reader to the basics of DevOps. It shows what is important to introduce DevOps in a company and how to create a successful DevOps team. In addition, it will be shown which processes exist in the context of DevOps and which tools can be used to implement DevOps development.

First, we will explain the basic idea of ​​DevOps and how it came. Afterwards it will be explained what has to be done in order to be able to use DevOps in the company and with which processes this can then be implemented. Finally, functions of some tools that can be used for DevOps development will be explained.

Basics of DevOps : Origin and Definition DevOps

When the first computers were used in companies in the 1960s, nobody knew how they should accompany working life. At this time “few thought about process models, division of labor organizational structures or elaborate governance models. Gradually, more and more minor software issues needed to be resolved to simplify certain features of the business process. With the help of the specialist department was the try to solve this problem with appropriate software. Since this usually had to be very complex, it meant that software soon became more expensive than the hardware. Also, the development of this software usually took a lot of time, so that the requests of the company soon exceeded the efficiency of the department. This is how the software crisis developed in the mid-sixties. But it also happened, because at that time there was little staff who could construct the needed software. And that happened long before the implementation of entire business processes, which consequently represented the next major obstacle.

At a NATO conference in 1968, the problem of the software crisis was discussed and discussed. Software engineering can be seen as a result of this discussion. This should henceforth be a design model for software development. Nevertheless, it is not clear at the time how this model should look like. The inventors of software engineering agree to orient themselves on an already solved problem from the beginning of the 20th century. Henry Ford had at the time developed a pattern to accelerate the production of cars enormously. Through his pattern he was able to increase production by significant orders of magnitude, which helped to meet the needs of the large market. Along with this, production was also implemented more cost-efficiently. The pattern provided split the production process into smaller steps and have them executed by specialists in the field. These small steps were done on a conveyor belt, which connected all steps of the production. This created a process that could be expanded or shortened as desired. The costs of production were reduced rapidly, partly because of the lot size effects and secondly, there was no need to hire expensive experts who could fully understand and assemble the car. There was now enough workforce to work on, showing a certain part of the production and running it over and over again. These basic ideas were taken up by the inventors of software engineering, thus developing the nonexistent model. These ideas took hold of the founders of software engineering, and thus process models, division of labor and specialization moved into IT: a distinction was made between analysis, design, implementation, testing, commissioning and operation, and the individual disciplines began to be developed further specialize.

The concept has been developed and redesigned over the years with the growing challenges in the IT industry. But the software crisis was never explained, which, strictly speaking, it is not. The demand for new software has continued to grow, and new goals for software have been declared that can not be implemented at first. For example, due to the fast pace of the industry, development should not take too long and must be offered at a low price due to the large market. This condition was regarded as normal after more than 20 years. Also because of the fast pace of the industry, these concepts must always be rethought. So the change of the PC from the luxury goods over to the everyday object in the early 90’s contributed among other things to the fact that the model had to be adjusted again. What’s more, companies’ systems have become increasingly networked, making it necessary to develop software for entire business processes. IT has developed so much today that it has become essential for a company and without it a normal operation of the company is unthinkable.

This renewed revision is largely responsible for the agile movement that developed in the 1990s, which fits in better with the changing demands on software and which, from today’s perspective, fits in better with the structure of the companies :

1. There has been a return to goodwill procedures
2. Accordingly responsibilities have been redistributed, eg in the form of a product owner at Scrum instead of project and product managers
3. The development cycles have become significantly shorter
4. Flexible response to changing requirements has been significantly improved
5. The process models have been streamlined
6. The hierarchies have generally flattened
7. Routine activities have been more automated to better handle the faster development cycles
8. Together with an intensified test automation this led to a better software quality
9. All approaches are based on a system of values, which – in contrast to Taylorism – focus on people and interactions

But even this form of software development does not take into account a fundamental characteristic of the IT department: The IT department usually consists of two areas of specialization, development and operation. The agile principles so far relate only to the field of development. As a result, the two areas are still separated during software development. This means that development is already fast and flexible according to the methods of agile movement, but the operation is still stuck in the old structures of software engineering. This eliminates the benefits of agile development, as a software release using traditional methods can still take months to complete. Furthermore, it is possible that components of the development, such as the monitorability, to fall by the wayside as a result of the different ways of working. Of course, the operation can intentionally delay the commissioning of the new software. Because of this problem, in 2009 the so-called “DevOpsDays” in Belgium was held. The aim of this conference was be to develop a methodology that brings development and operation closer together. The result is the term “DevOps”, which consists of Dev (development development) and Ops (operations IT operation) and has since stood for this new methodology held in Belgium. The aim of this conference should be to develop a methodology that brings development and operation closer together.

Even after this long time, there is no fixed definition for DevOps. Here are some definitions listed to clarify how different this term can be understood and what broad spectrum is summarized in it.

DevOps is a mix of well-known, advanced practices and new, innovative approaches to existing projects. DevOps is the practice of operations and development engineers participating in the entire service lifecycle, from design through development to production support. The term is composed of “Dev”, which represents the software developers (Developers), and “Ops “, the one for the IT operation (Operations) The combination of the common “DevOps” intuitively symbolizes a solidarity between software developers and IT operations. DevOps has taken up the ideas of Agile operations and has been able to formulate various goals in recent years. The goals can be divided into three areas : Collaboration, automation and processes.

The goal of automation, is to facilitate the automation of operations in IT operations and the sharing of tools between development and operations. The goal in the area of ​​processes should be to define suitable processes for the introduction and use of DevOps ideas.

Conclusion on Part 1 of Basics of DevOps

The term DevOps has been around since 2009. For the IT world, this is a long period of 10 years. Most topics are outdated again. DevOps is different. The aim of the collaboration should be to use the agile principles of software engineering across departments and thus to derive added value from the cooperation. In this Part 1 of the series on Basics of DevOps, we learned the origin and definition of DevOps.

Click here to continue to read Part 2 of Basics of DevOps.