This is an accepted version of this page DevOps is the integration and automation of the software development and information technology operations [a].
[1] According to Neal Ford, DevOps, particularly through continuous delivery, employs the "Bring the pain forward" principle, tackling tough tasks early, fostering automation and swift issue detection.
From an academic perspective, Len Bass, Ingo Weber, and Liming Zhu—three computer science researchers from the CSIRO and the Software Engineering Institute—suggested defining DevOps as "a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality".
[8] Proposals to combine software development methodologies with deployment and operations concepts began to appear in the late 80s and early 90s.
[28] Contrary to the "top-down" prescriptive approach and rigid framework of ITIL in the 1990s, DevOps is "bottom-up" and flexible, having been created by software engineers for their own needs.
Agile development teams using methods such as extreme programming couldn't "satisfy the customer through early and continuous delivery of valuable software"[30] unless they took responsibility for operations and infrastructure for their applications, automating much of that work.
ArchOps presents an extension for DevOps practice, starting from software architecture artifacts, instead of source code, for operation deployment.
[32] Plus, improved collaboration and communication between and within teams helps achieve faster time to market, with reduced risks.
In 2003, Google developed site reliability engineering (SRE), an approach for releasing new features continuously into large-scale high-availability systems while maintaining high-quality end-user experience.
[36] Toyota production system, also known under the acronym TPS, was the inspiration for lean thinking with its focus on continuous improvement, kaizen, flow and small batches.
The andon cord principle to create fast feedback, swarm and solve problems stems from TPS.
The software composition is analyzed, especially libraries, and the version of each component is checked against vulnerability lists published by CERT and other expert groups.
[46] It also supports consistency, reliability, and efficiency within the organization, and is usually enabled by a shared code repository or version control.
As explained by Red Hat, "visibility to change means the ability to trace and reproduce issues quickly, improving overall security.