DevOps
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).
History
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.[1]
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:
- bring an application to the market faster,
- fewer errors and bugs found in the application,
- updates can be made at more frequent intervals,
- in the event of a system crash, the time it takes to reboot the system is shorter. .[2]
Functionality
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.[3] 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.
Three basic elements of DevOps
DevOps is often characterized by three key elements. They describe the main thrust of the approach.
- Cooperation: DevOps advocates are committed to mutual respect which is supposed to shape the communication between the R&D department and IT operations. Respect is the basis for trust and a good working relationship. The commitment of all participants towards common goals, and attentive listening have a part in it. Fruitful communication needs to be established as a cultural practice across departments.
- Automation: From the standpoint of quality control some manual tasks create problems because they are only slightly transparent and cannot be transferred to other departments. This is avoided by the use of tools that are available for all those involved. The most significant component is the infrastructure as code. The source code of an application already contains data during its development stage that determine the installation, configuration and use of the code in the IT infrastructure more closely. Configurations can therefore be quickly simulated and tested for example. Central version management and sharing of rules for the various phases of a project are likewise included. Tools like Puppet or Chef can be used to unify the configuration management. Version control software such as Git or Mercurial can be used. Automated testing of source code is often done with BDD (behavior-driven development) tools that are compatible with configuration management. In this context, continuous integration servers are also an option if software is to be delivered by the Continuous Delivery principle. The aim of many of these tools is to avoid conflicts between departments and the infrastructure used.
- Processes: The introduction of the DevOps concept is closely associated with the establishment of mandatory processes that optimize the workflow. However, these processes are very different when different sizes of companies come into play. In small companies, for example, the server environments are often not strictly separated from one another, which is quite different in large companies. The question is whether mandatory processes enhance the practical use of DevOps or make it more complex. Work is underway currently to develop DevOps procedures for small, medium and large businesses.
Importance for programming
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.
References
- ↑ [http://www.jedi.be/presentations/agile-infrastructure-agile-2008.pdf Agile Infrastructure & Operations] jedi.be. Accessed on 10/26/2015
- ↑ What is DevOps? newrelic.com. Accessed on 10/26/2015
- ↑ What Is This Devops Thing, Anyway? jedi.be. Accessed on 10/26/2015