for optimal display of the Core model, rotate your device to landscape mode
The use of a version control system, such as Git or Subversion, for all production artifacts, including application code, application configurations, system configurations, and scripts for automating build and configuration of environments.
Systems and tools that make it easy for developers to change code maintained by others, to find examples in the codebase, to reuse other people’s code, and to add, upgrade, and migrate to new versions of dependencies without breaking their code.
Teams can be said to have implemented continuous delivery when they have achieved the following outcomes:
Continuous delivery requires the implementation of a number of technical practices including continuous integration, trunk-based development, the comprehensive use of version control, and continuous testing.
In turn, continuous delivery drives a number of outcomes: higher software delivery performance, better organizational culture, less rework, lower deployment pain, and less burnout.
A development practice where code is regularly checked in, and each check-in triggers a set of quick tests to discover regressions, which developers fix immediately. The CI process creates canonical builds and packages that are ultimately deployed and released.
Database changes don’t slow teams down if they follow a few key practices, including storing database changes as scripts in version control (and managing these changes the same way as production application changes), making database changes visible to everyone in the software delivery lifecycle (including engineers), and communicating with all parties when changes to the application require database changes.
The degree to which deployments are fully automated and do not require manual intervention.
Teams that can choose which tools to use do better at continuous delivery. No one knows better than practitioners what they need to be effective.
Infrastructure flexibility is often a motivation for organizations to adopt cloud computing. However, the use of a cloud provider alone may not be sufficient to achieve the desired agility. DORA’s research uses a definition from The USA’s National Institute of Standards and Technology (NIST) to establish the five essential characteristics that enable cloud computing to provide its full potential benefit to an organization:
Architecture that lets teams test and deploy their applications on demand, without requiring orchestration with other services. Having a loosely coupled architecture allows your teams to work independently without relying on other teams for support and services, which in turn enables them to work quickly and deliver value to the organization.
Shift security concerns to the “left”—that is, earlier in the software delivery lifecycle (SLDC)—by integrating security into the design and testing phases of the software development process. This process includes conducting security reviews of applications, including the infosec team in the design and demo process for applications, using pre-approved security libraries and packages, and testing security features as a part of the automated test suite.
Test throughout the software delivery lifecycle, rather than as a separate phase after “dev complete.” With continuous testing, developers and testers work side by side. High performers practice test-driven development, get feedback from tests in less than ten minutes, and continuously review and improve their test suites (for example, to better find defects and keep complexity under control).
The management of test data is an increasingly important part of automated testing. Effective practices include having adequate data to run your test suite, the ability to acquire necessary data on demand, and the data not limiting the number of tests you can run. We caution that your teams should minimize, whenever possible, the amount of test data needed to run automated tests.
Characterized by minimizing the number of active branches in a code repository; branches and forks having very short lifetimes (e.g., less than a day) before being merged into main; and application teams rarely or never having “code lock” periods when no one can check in code or do pull requests due to merging conflicts, code freezes, or stabilization phases.
Monitoring and observability tooling allows teams to understand the health of their systems. Effective solutions enable teams to monitor predefined metrics, including system state as experienced by users, as well as allowing engineers to interactively debug systems and explore properties and patterns as they emerge.
Documentation quality interacts with technical capabilities to improve organizational performance. This interaction dramatically amplifies the impact that software teams can deliver toward achieving an organization’s overarching goals. Practices which contribute to documentation quality include:
This measure of organizational culture is based on a typology developed by Ron Westrum, a sociologist who studied safety-critical complex systems in the domains of aviation and healthcare. Our own research has found that this measure of culture is predictive of IT Performance, organizational performance, and decreasing burnout. Hallmarks of this include good information flow, high cooperation and trust, bridging between teams, and embracing novel solutions.
Most IT organizations have change management processes to manage the life cycle of changes to IT services, both internal and customer-facing. These processes are often the primary controls to reduce the operational and security risks of change. Change management processes often include approvals by external reviewers or change approval boards (CABs) to promote changes through the system.
Our research shows that formal change management processes that require the approval of an external body such as a change advisory board (CAB) or a senior manager have a negative impact on software delivery performance. Furthermore, we found no evidence to support the hypothesis that a more formal approval process is associated with lower change fail rates. However the data does support the hypothesis that introducing more approvals results in a slower process and less frequent releases of large batches, with an accompanying higher impact on the production system that is likely associated with higher levels of risk and thus higher change fail rates.
Well-being is a reflection of individuals’ happiness and job satisfaction. Increased well-being predicts organizational performance and employees’ job tenure. DORA has studied the impact of deployment pain, rework, and burnout on well-being.
Deployment pain is a measure of the fear and anxiety that engineers and technical staff feel when they push code into production.
Rework is reactive unplanned work, including any break/fix work, emergency software deployments and patches, responding to urgent audit documentation requests, and so on.
Burnout is physical, mental, or emotional exhaustion caused by overwork or stress.
Organizational performance measures the ability of an organization to achieve commercial and non-commercial goals. Academic research has validated this measure and found it to be highly correlated to measures of return on investment (ROI), and it is robust to economic cycles.
Combined, commercial and non-commercial goals include:
Several years of analysis shows that, compared to low performers, organizations with the highest level of software delivery performance are twice as likely to exceed their goals. Employee well-being also contributes to organizational performance.
Read the whitepaper: ROI of DevOps Transformation
DORA’s research has consistently found that a team’s software delivery capability reliably predicts the value that the team provides to their organization. Survey respondents who achieve high levels of software delivery performance report that their organizations perform better on business objectives. Performance can be assessed according to four software delivery metrics:
For the primary application or service you work on…
Lead time for changes: How long does it take to go from code committed to code successfully running in production?
Deployment frequency: How often does your organization deploy code to production or release it to end users?
Change failure rate: What percentage of changes to production or released to users result in degraded service (e.g., lead to service impairment or service outage) and subsequently require remediation (e.g., require a hotfix, rollback, fix forward, patch)?
Time to restore service: How long does it generally take to restore service when a service incident or a defect that impacts users occurs (e.g., unplanned outage, service impairment)?
Want to assess your team’s software delivery performance? Try our DORA Quick Check for insights on how to improve.
About this model: DORA Core is a collection of capabilities, metrics, and outcomes that represent the most firmly-established findings from across the history and breadth of DORA’s research program. Core is derived from DORA’s ongoing research, including the analyses presented in our annual Accelerate State of DevOps Reports. Core is intended to be used as a guide in practitioner contexts: it deliberately trails the research, evolving more conservatively. The concepts and relationships shown in the Core Model have been repeatedly demonstrated by our research, and have been successfully used by software engineering teams to prioritize continuous improvement. (FAQ)
Learn more about DORA's Research Team
