The DevOps Research and Assessment (DORA) metrics revolutionized how the software industry measures software organization performance and delivery capabilities. In this article we show you how you can use create a custom graph in Spira that displays the standard DORA Metric: Mean Time To Recover.
Mean Time to Recover (MTTR) measures how quickly you restore normal service after a production incident, defined as the elapsed time from incident start or detection (e.g., alert fired, SLO breach began) to service restoration (impact ended/SLO back in compliance).
Compute it per service over a recent window as a distribution (median/P90 plus counts), using incident-management timestamps or monitoring data; include incidents tied to deployments as well as other causes unless you explicitly scope to change-related failures. MTTR highlights the effectiveness of detection, rollback/roll-forward, and on-call practices—short MTTR paired with a low Change Failure Rate indicates strong resilience and recovery discipline.
The DevOps Research and Assessment (DORA) metrics revolutionized how the software industry measures software organization performance and delivery capabilities. In this article we show you how you can use create a custom graph in Spira that displays the standard DORA Metric: Change Failure Rate.
Change Failure Rate is the percentage of production deployments that cause a service degradation and require remediation—such as a rollback, hotfix, or incident—within a defined window. Compute it as: failures ÷ total successful production deployments (e.g., in the last 30 or 90 days), where “failure” is operationally defined up front (sev-1/2 incidents, rollbacks, emergency patches, feature flags forced off, etc.).
Measure and report it per service/team to avoid averaging away hotspots, and show both the rate and the underlying counts. Track alongside Mean Time to Recover (MTTR): a low CFR with fast restore times indicates healthy quality and recovery; a high CFR suggests issues in testing, change size, approvals, or release practices.
The DevOps Research and Assessment (DORA) metrics revolutionized how the software industry measures software organization performance and delivery capabilities. In this article we show you how you can use create a custom graph in Spira that displays the standard DORA Metric: Deployment Frequency.
Deployment Frequency is how often your organization successfully deploys code to production, typically counted as the number of production releases per service (or product) over a standard interval (e.g., per day or per week). It reflects delivery cadence and should be normalized by system/team to avoid masking variation; only successful production deployments are counted, while rollbacks are excluded or tracked separately.
Report it as a time series (e.g., weekly counts and moving averages) and pair with Lead Time for Changes: elite teams ship many small releases frequently (often daily or more), while lower frequencies can signal batching, manual gates, or pipeline friction.
The DevOps Research and Assessment (DORA) metrics revolutionized how the software industry measures software organization performance and delivery capabilities. In this article we show you how you can use create a custom graph in Spira that displays the standard DORA Metric: Lead Time To Change inside Spira.
The Lead Time to Change measures how long it takes a code change to reach users, defined as the elapsed time from when a change is integrated (typically a PR is merged to the main branch) to when a successful production deployment that includes that change finishes. It captures the speed of your delivery pipeline.
Shorter lead times generally indicate smoother, more automated paths to production and tighter feedback loops, especially when paired with healthy deployment frequency; longer times can reveal bottlenecks in reviews, builds, approvals, or release practices.
Although most of our customers are using the Inflectra.ai native artificial intelligence functionality in our platforms, we also offer options for customers to use OpenAI hosted in Microsoft Azure as an alternative. This is useful for customers that are using Microsoft Azure rather than Amazon Web Services (AWS). In this article we provide the technical architecture information for integrating Spira and Rapise with OpenAI.
Recommended approach is to use SpiraTest and RapiseLauncher designed for this task. In some cases it is not an option and we need to execute a test directly.
Note: this manual is out of date. Please refer to the new one for Jenkins 2.440 instead.
In order to synchronize SpiraTest, SpiraTeam, or SpiraPlan with Microsoft Azure DevOps (ADO) formerly known as Microsoft Team Foundation Services (TFS) you may need the IDs of the Areas inside ADO. This article describes how you can get this from cloud instances of ADO where you do not have access to the database.
When you integrate Spira with Microsoft Azure DevOps you might get error records generated in your Event Log, while all expected artifacts are being synced.
This guide explains the meaning of the error codes and possible causes.
Recently (starting in March 22nd, 2022, but later for some customers) Microsoft removed support for TLS 1.0 and 1.1 endpoints. If you are using an on-premise version of Spira, or a cloud version that uses an on-premise data-synchronization utility, you may get the TFS error: TF400324
When using SpiraPlan, SpiraTest or SpiraTeam with Microsoft Azure DevOps instead of a local installation of Microsoft Team Foundation Server there are a couple of differences in the integration configuration that you will want to be aware of. This article describes those differences.
When you integrate Spira with Microsoft Azure DevOps (formerly known as Team Foundation Server or TFS) you have the option of matching up the custom properties in Spira with the user defined fields in Azure DevOps. This guide explains how you get the 'system names' for custom vs. standard fields.
When you are first using the SpiraTeam plugin for JetBrains TeamCity, you may run into the issue where the settings for TeamCity are not being saved correctly.