How Is DevOps Performance Measured?

How Is DevOps Performance Measured? - by Tiffany Jachja

After six years’ worth of surveys, the DevOps Research and Assessments (DORA) team identified four key measures for DevOps performance. These four DevOps metrics include deployment frequency, mean lead time for changes, mean time to recover, and change failure rate. By tracking these metrics, teams can better understand their DevOps challenges and take data-driven action.

These metrics align with various DevOps characteristics, including speed, repeatability, visibility, and reliability.

What Does DevOps Mean to Your Organization?

Answering this question is a great way to identify what capabilities and implementations should take priority. Many DevOps teams choose to focus on a cloud or container-native strategy involving Kubernetes, automation, or security. Continuous Integration and Continuous Delivery (CI/CD) is a great place to start to secure a foundation for delivery velocity, feedback loops, and other DevOps capabilities. 

Continuous Integration (CI) is a great starting point for many teams to focus on because DevOps relies on delivering well-defined and well-functioning software-developed features. The remainder of this post will go into further detail on improving your Continuous Integration process.

Identifying Your Challenges in Continuous Integration

To identify your challenges in Continuous Integration, we need to define what is Continuous Integration and what does the process involve.

Continuous Integration (CI) is an automated process for continually integrating software development changes. CI processes automate the building, testing, and validation of source code. By working with CI capabilities, developers can accelerate their code release cycles, and facilitate quick feedback, making it less likely to run into long feature development cycles and the challenges of merge conflicts.

The typical CI pipeline automates the following workflow:

1. A developer pushes changes into a version-controlled repository and triggers the CI pipeline
2. The CI server fetches changes to the application code (sometimes static code analysis is done here)
3. The CI server builds the code, creating a compiled executable version of the application 
4. The CI server launches the test suite
5. After the tests run, the CI server fails or passes the build to be tagged, scanned, and deployed
6. Notification of the success or failure is sent to the development team

For many teams, a development cycle begins with well-defined requirements that are often sized by story points. Development team members then work through sprints or increments of time to deliver new features or enhancements to existing features. During a sprint, developers will commit and push changes to a code repository for versioning. This often triggers a CI pipeline to build the code-based and launch test processes. These suites of tests can include unit tests, load tests, and other forms of performance testing.

After the tests pass and the CI pipeline succeeds, the CI pipeline solution will produce a packaged artifact suitable for a deployment or CD pipeline. If the build process fails, or if there are failed tests, developers will review their broken builds to make bug fixes and code changes. While this workflow may change for special cases, teams should leverage their CI pipeline as the source of truth for building packaged and well-tested artifacts. 

Based on this CI workflow, developers may have particular challenges in version control, building, testing, CI governance, or continuous feedback. It may be worth it for you to read our article, “What is Continuous Integration?” if you’d like to learn more about CI. 

Read more here: https://harness.io/blog/continuous-integration/continuous-integration-performance-metrics/