The term DevOps is a combination of development and operations. As a concept, DevOps emphasizes the communication and cooperation between these two departments in the development of application software, applications, and web applications. Tools that span these departments are also put to use. The aim is to design the life cycle of applications in such a way that application development and IT operations cooperate more closely and thereby avoid silos. DevOps strategies often play a role in the areas of lean management and agile software development. They are also a prerequisite for the software delivery process called Continuous Delivery (CD).
Patrick Debois chose the name DevOpsDays for a conference that he organized in Ghent, Belgium, in 2009. In subsequent years, the term DevOps has always been associated with agile methods, since the conference dealt with these issues. The conference and in particular, Debois’ lecture focused on the topic of collaboration of programmers, IT specialists, and operative production management, as well as the requirements of agile methods for a change of this cooperation.
The classic cascade model in software development was obviously not sufficient to give due consideration to agile processes. Different departments were agile in varying degrees. In other words, product management, IT and development could not work together because the development area was oriented around agility, but the other two departments were still working according to old patterns (cascade model and DTAP). DevOps is meant to overcome these barriers in terms of communication and cooperation, by integrating the concept throughout the entire lifecycle of an application and introducing the use of configuration, version management and testing tools. DevOps can result in the following advantages:
Conventional development models of applications are divided into phases or functional units. The DTAP paradigm (Development, Testing, Acceptance and Production), for example, not only includes different teams, but also appropriate infrastructures (see Staging and Testing Environment). Software would be developed, tested and quality checked before it is migrated to a production environment according to this paradigm.
When transferring the applications, conflicts often occur because the infrastructures differ, for example, development works with testing and debugging tools, while the production environment simulates real user conditions and cannot rely on such tools. Once such conflicts arise, conflicts of interest of the involved parties can be the result, because they tend to work in silos and a real exchange of information hardly takes place. If something is not working as desired, the responsibility for it is shunted back and forth between departments. This practice often found in corporations is detrimental to revenue. DevOps emerged from experience with IT conflicts and conflicts of interests.
DevOps begins with these conflicts and tries to establish a framework which enables agile software development not only technically, but also humanly. Otherwise, the benefits of agile methods would not be noticeable and the teams would be busy trying to smooth out the conflicts instead of improving the software and facilitating its release. Cooperation between development and IT operations is the focus of DevOps, but aspects such as automation and agreement on standardized processes throughout the lifecycle of software also play a role.
DevOps is often characterized by three key elements. They describe the main thrust of the approach.
The DevOps concept aims to establish agile methods across departments to make the development and release process for applications faster, high-quality and low-conflict. The financial added value that the participants can generate through DevOps is an important factor for the introduction of the concept. Only when the methods and tools used actually result in financial profitability for the applications being published will DevOps be an alternative for decision-makers in companies. The improvement of communication and cooperation is undoubtedly desirable, but the lack of standardized processes is a problem specifically in large companies, especially since automated processes call for fundamental changes to the infrastructure and daily practice. Ultimately, it’s the result that counts and as far as that is concerned, agile methods and related concepts are in the same situation and necessitate proof based on case studies and success stories.