Skip to main content

Improvements to your DevOps performance metrics calculations

We've made improvements to how your DORA metrics are calculated, making them faster to load and more accurate.

Written by Brandon Chin Loy

What's changed?

We've updated how metrics are calculated and displayed in the DevOps performance dashboard in Pipelines. The new approach is more robust, transparent and auditable.

For most customers, the numbers you see will remain the same or very close to what they were before. For a small number of customers, you may notice a change in your deployment frequency and, in some cases, your lead time for changes. Both changes reflect more accurate data as explained below.

Deployment Frequency

What's changed?

Deployment frequency now only counts deployments that contained actual changes to your Salesforce org, meaning deployments that included at least one metadata or data configuration change.

Previously, the count could include deployments where a CI job was triggered but there was nothing to deploy (for example, a manually triggered pipeline run with no pending changes). These are not meaningful deployments because no change was made to your org, and including them was inappropriately inflating the figure.

What to expect?

If your team occasionally triggers empty CI job runs, your deployment frequency figure may be lower than before. This is the correct, more accurate value. It reflects the number of times your team actually shipped changes to production.

Note: Not every deployment will have an associated lead time for changes. For example, if a commit is pushed directly to the main branch and a CI job is triggered, there is no pull request to measure lead time against. Similarly, rollbacks will appear in your deployment frequency count but will contribute to your mean time to restore rather than lead time for changes. Both of these are expected behaviours.

Lead Time for Changes

What's changed?

We've improved how lead time for changes entries are linked to deployments. Every entry is now directly traceable to a specific production deployment, making it much easier to understand and audit your data. Note that the reverse is not always true: as described above, some deployments will not have an associated lead time for changes entry.

What to expect?

You may see minor adjustments to individual lead time values. These reflect a more accurate calculation. The underlying data (your pull requests and deployment history) has not changed, but the way we aggregate and link that data to specific deployments is now more precise and consistent.

Performance Improvements

In addition to the accuracy improvements, metrics now load significantly faster:

  • Metrics load faster: Metrics no longer require real-time calls to your version control system. All the data needed is stored and maintained on Gearset's side.

  • Loading metrics no longer affects other Pipelines activity (if previously experienced): Previously, for some teams with high pipeline activity, loading metrics could temporarily slow down or block other pipelines actions, such as opening or promoting pull requests. This is no longer the case.

Is my underlying data still the same?

Yes. No historical deployment or pull request data has been changed, removed or modified. The improvements are entirely in how we store the links between that data and compute the metrics from it. These improvements give us a clearer, more auditable trail from each deployment back to the pull requests that contributed to it, which is what makes the calculations more accurate.

Do I need to do anything?

No action is required. The updated metrics will appear automatically in your DevOps performance dashboard. If you are using the Reporting API to pull DORA metrics into an external tool, updated API documentation for the new endpoints will be available in the future. We will communicate separately when those are ready.

Questions?

If you have any questions about your specific metrics or want help interpreting a change you have noticed, please reach out to our team.

Did this answer your question?