DevOps

DevOps is the integration and automation of software development and information technology operations.^[a] DevOps encompasses the tasks necessary for software development and can lead to shortening development time and improving the development life cycle.^[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.^[2] Software programmers and architects should use fitness functions to keep their software in check.^[3]

Although debated,^[b][c][d][e] DevOps is characterized by key principles: shared ownership, workflow automation, and rapid feedback. 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".^[7] However, the term is used in multiple contexts. At its most successful, DevOps is a combination of specific practices, culture change, and tools.^[8]

Proposals to combine software development methodologies with deployment and operations concepts began to appear in the late 80s and early 90s.^[9]

In 2008, Tim O’Reilly supported Steve Souders and Jesse Robbins in creating and co-chairing the first O'Reilly Velocity Conference, bringing together the web performance and operations community.^[10][11]

In 2009, the first conference named DevOps Days was held in Ghent, Belgium. The conference was founded by Belgian consultant, project manager and agile practitioner Patrick Debois.^[12][13] The conference has now spread to other countries.^[14]

In 2012, a report called "State of DevOps" was first published by Alanna Brown at Puppet Labs.^[15][16]

As of 2014, the annual State of DevOps report was published by Nicole Forsgren, Gene Kim, Jez Humble and others. They stated that the adoption of DevOps was accelerating.^[17][18] Also in 2014, Lisa Crispin and Janet Gregory wrote the book More Agile Testing, containing a chapter on testing and DevOps.^[19][20]

In 2016, the DORA metrics for throughput (deployment frequency, lead time for changes), and stability (mean time to recover, change failure rate) were published in the State of DevOps report.^[15] However, the research methodology and metrics were criticized by experts.^{[21][22][23][24]} In response to these criticisms, the 2023 State of DevOps report ^[25] published changes that updated the stability metric "mean time to recover" to "failed deployment recovery time" acknowledging the confusion the former metric has caused.^[26]

DevOps Research and Assessment (DORA) has developed a series of metrics which are intended to measure software development efficiency and reliability. These metrics include:^[27][28]

• Deployment Frequency: Time between code deployments.
• Mean Lead Time for Changes: Time between code commit and deployment.
• Change Failure Rate: Percentage of deployments causing production issues.
• Failed Deployment Recovery Time (formerly Mean Time To Recover)
• Reliability (added in 2021): Measures operational performance, focusing on availability and adherence to user expectations.

Many of the ideas fundamental to DevOps practices are inspired by, or mirror, other well known practices such as Lean and Deming's Plan-Do-Check-Act cycle, through to The Toyota Way and the Agile approach of breaking down components and batch sizes.^[29] 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.^[30]

Platform engineering is an emerging discipline within software engineering that supports DevOps by building and maintaining internal developer platforms (IDPs). These platforms provide standardized tools and reusable components—such as CI/CD pipelines, infrastructure provisioning, observability, and security controls—to streamline software delivery and reduce the cognitive load on developers. The goal is to enable self-service capabilities, improve productivity, and ensure consistency across development and operations teams.^[31][32]

The motivations for what has become modern DevOps and several standard DevOps practices such as automated build and test, continuous integration, and continuous delivery originated in the Agile world, which dates (informally) to the 1990s, and formally to 2001. Agile development teams using methods such as extreme programming couldn't "satisfy the customer through early and continuous delivery of valuable software"^[33] unless they took responsibility for operations and infrastructure for their applications, automating much of that work. Because Scrum emerged as the dominant Agile framework in the early 2000s and it omitted the engineering practices that were part of many Agile teams, the movement to automate operations and infrastructure functions splintered from Agile and expanded into what has become modern DevOps. Today, DevOps focuses on the deployment of developed software, whether it is developed using Agile oriented methodologies or other methodologies.

ArchOps presents an extension for DevOps practice, starting from software architecture artifacts, instead of source code, for operation deployment.^[34] ArchOps states that architectural models are first-class entities in software development, deployment, and operations.

Automation is a core principle for achieving DevOps success and CI/CD is a critical component.^[35] Plus, improved collaboration and communication between and within teams helps achieve faster time to market, with reduced risks.^[36]

Database DevOps applies DevOps and CI/CD principles directly to database development and operations. Integrating schema changes, migrations, reference data, and other data-layer updates into the same version-controlled and automated pipelines used for application code enables more reliable deployments and better coordination between application and data changes.^[37][38]

Typical practices documented in both research and industry benchmarks include placing database schema definitions under version control, applying automated tests (such as unit tests or migration validation) to database changes, and deploying those changes through CI/CD pipelines. These practices reduce "schema drift" between development and production systems and lower the risk of deployment failures.^[39][40]

Mobile DevOps is a set of practices that applies the principles of DevOps specifically to the development of mobile applications. Traditional DevOps focuses on streamlining the software development process in general, but mobile development has its own unique challenges that require a tailored approach.^[41] Mobile DevOps is not simply a branch of DevOps specific to mobile app development, but rather an extension and reinterpretation of the DevOps philosophy tailored to the mobile domain's specific requirements.

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.^[42] While SRE predates the development of DevOps, they are generally viewed as being related to each other. Some of the original authors of the discipline consider SRE as an implementation of DevOps.^[43]

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.^[44][45]

DevSecOps is an augmentation of DevOps to allow for security practices to be integrated into the DevOps approach. Contrary to a traditional centralized security team model, each delivery team is empowered to factor in the correct security controls into their software delivery. Security practices and testing are performed earlier in the development lifecycle, hence the term "shift left". Security is tested in three main areas: static, software composition, and dynamic.

Checking software statically via static application security testing (SAST) is white-box testing with special focus on security. Depending on the programming language, different tools are needed to do such static code analysis. 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. When giving software to clients, library licenses and their match to the license of the software distributed are in focus, especially copyleft licenses.

In dynamic testing, also called black-box testing, software is tested without knowing its inner functions. In DevSecOps this practice may be referred to as dynamic application security testing (DAST) or penetration testing. The goal is early detection of defects including cross-site scripting and SQL injection vulnerabilities.

Often, detected defects from static and dynamic testing are triaged and categorized under taxonomies like the Common Weakness Enumeration (CWE), maintained by the Mitre Corporation. This facilitates the prioritization of security bug fixes and also allows frequently recurring weaknesses to be fixed with recommended mitigations. As of 2025, CWE maintained its own list of frequently-occurring weaknesses, the CWE Top 25.^[46] In addition, organizations like Open Worldwide Application Security Project (OWASP) maintain lists of industry-wide frequently recurring software weaknesses.^[47]

DevSecOps has also been described as a cultural shift involving a holistic approach to producing secure software by integrating security education, security by design, and security automation.^[48]

DevOps initiatives can change how a company's operations, developers, and testers collaborate during the development and delivery processes.^[49][50]

DevOps attempts to support consistency, reliability, and efficiency within an organization. This is usually enabled by a shared code repository or version control.^[51] Many organizations use version control to facilitate DevOps automation technologies like virtual machines, containerization (or OS-level virtualization), and CI/CD,^[52] with the Git version control system and the GitHub platform referenced as examples.

GitOps evolved from DevOps. The specific state of deployment configuration is version-controlled. Because the most popular version-control is Git, the GitOps approach has been named after Git. Changes to configuration can be managed using code review practices, and can be rolled back using version-controlling. Essentially, all of the changes to a code are tracked, bookmarked, and making any updates to the history can be made easier. As explained by Red Hat, "visibility to change means the ability to trace and reproduce issues quickly, improving overall security."^[53]

The following practices can enhance productivity of DevOps pipelines, especially in systems hosted in the cloud:^[54][55][56]

• Number of Pipelines: Small teams can be more productive by having one repository and one pipeline. In contrast, larger organizations may have separate repositories and pipelines for each team or even separate repositories and pipelines for each service within a team.
• Permissions: In the context of pipeline-related permissions, adhering to the principle of least privilege can be challenging due to the dynamic nature of architecture. Administrators may opt for more permissive permissions while implementing compensating security controls to minimize the blast radius.

DataOps is a set of practices, processes and technologies that combines an integrated and process-oriented perspective on data with automation and methods from agile software engineering to improve quality, speed, and collaboration and promote a culture of continuous improvement in the area of data analytics.^[57] While DataOps began as a set of best practices, it has now matured to become a new and independent approach to data analytics.^[58] DataOps applies to the entire data lifecycle^[59] from data preparation to reporting, and recognizes the interconnected nature of the data analytics team and information technology operations.^[60]

DataOps incorporates the Agile methodology to shorten the cycle time of analytics development in alignment with business goals. ^[59]

DevOps focuses on continuous delivery by leveraging on-demand IT resources and by automating test and deployment of software. This merging of software development and IT operations has improved velocity, quality, predictability and scale of software engineering and deployment. Borrowing methods from DevOps, DataOps seeks to bring these same improvements to data analytics.^[60]

DataOps utilizes statistical process control (SPC) to monitor and control the data analytics pipeline. With SPC in place, the data flowing through an operational system is constantly monitored and verified to be working. If an anomaly occurs, the data analytics team can be notified through an automated alert.^[61]

DataOps is not tied to a particular technology, architecture, tool, language or framework. Tools that support DataOps promote collaboration, orchestration, quality, security, access and ease of use.^[62]

DataOps was first introduced by Lenny Liebmann, Contributing Editor, InformationWeek, in a blog post on the IBM Big Data & Analytics Hub titled "3 reasons why DataOps is essential for big data success" on June 19, 2014.^[63] The term DataOps was later popularized by Andy Palmer of Tamr and Steph Locke.^[64][60] DataOps is a moniker for "Data Operations."^[59] 2017 was a significant year for DataOps with significant ecosystem development, analyst coverage, increased keyword searches, surveys, publications, and open source projects.^[65] Gartner named DataOps on the Hype Cycle for Data Management in 2018.^[66]

The volume of data is forecast to grow at a rate of 32% CAGR to 180 Zettabytes by the year 2025 (Source: IDC).^[62] DataOps seeks to provide the tools, processes, and organizational structures to cope with this significant increase in data.^[62] Automation streamlines data preboarding, ingestion, and the management of large integrated databases, freeing the data team to develop new analytics in a more efficient and effective way.^[67][60] DataOps seeks to increase velocity, reliability, and quality of data analytics.^[68] It emphasizes communication, collaboration, integration, automation, measurement and cooperation between data scientists, analysts, data/ETL (extract, transform, load) engineers, information technology (IT), and quality assurance/governance.

Toph Whitmore at Blue Hill Research offers these DataOps leadership principles for the information technology department:^[58]

• “Establish progress and performance measurements at every stage of the data flow. Where possible, benchmark data-flow cycle times.
• Define rules for an abstracted semantic layer. Ensure everyone is “speaking the same language” and agrees upon what the data (and metadata) is and is not.
• Validate with the “eyeball test”: Include continuous-improvement -oriented human feedback loops. Consumers must be able to trust the data, and that can only come with incremental validation.
• Automate as many stages of the data flow as possible including BI, data science, and analytics.
• Using benchmarked performance information, identify bottlenecks and then optimize for them. This may require investment in commodity hardware, or automation of a formerly-human-delivered data-science step in the process.
• Establish governance discipline, with a particular focus on two-way data control, data ownership, transparency, and comprehensive data lineage tracking through the entire workflow.
• Design process for growth and extensibility. The data flow model must be designed to accommodate volume and variety of data. Ensure enabling technologies are priced affordably to scale with that enterprise data growth.”

• Data Opticon^[69]
• Data Ops Summit^[70]
• Data Ops Online Champion^[71]

• DevOps toolchain – Tools for software development
• Infrastructure as code – Data center management method
• Lean software development – Use of lean manufacturing principles in software development
• List of build automation software
• Site reliability engineering – Use of software engineering practices for IT
• Value stream – Principle in economics
• Twelve-Factor App methodology – Software methodology

• Davis, Jennifer; Daniels, Ryn (2016-05-30). Effective DevOps: building a culture of collaboration, affinity, and tooling at scale. Sebastopol, CA: O'Reilly. ISBN 978-1-4919-2643-7. OCLC 951434424.
• Kim, Gene; Debois, Patrick; Willis, John; Humble, Jez; Allspaw, John (2015-10-07). The DevOps handbook: how to create world-class agility, reliability, and security in technology organizations (First ed.). Portland, OR. ISBN 978-1-942788-00-3. OCLC 907166314.{{cite book}}: CS1 maint: location missing publisher (link)
• Forsgren, Nicole; Humble, Jez; Kim, Gene (27 March 2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (First ed.). IT Revolution Press. ISBN 978-1-942788-33-1.