DORA Configuration
- Shir Koretski
You can choose how to pull your data for the DORA metrics with different configuration options.
To configure the metrics, click on “DORA” in the lefthand sidebar and select “Configure” on the top right.
You will get the following screen with the next options:
Supported Metric Variations:
Deploy Frequency
Ticket Completion - Fallback option
Use this option if you don’t have a build tool connected or don’t want to set up webhooks. If you have a ticket type that represents your releases (or can create one), Allstacks will measure when tickets that meet this definition are completed and report this as the deploy frequency.
Advanced filters are used to filter to JUST the tickets that represent releases.
Build Success Rate - Fallback option
Use this option if you would like to filter your build success metric to just the jobs that represent their deploys to production. This will work only if you are using a supported build tool and the structure of your deploy process is extremely low complexity.
Webhooks - Recommended Option
In this method, you will use webhooks to tell Allstacks whenever a deploy to production happens.
Advanced filters are available to narrow the deploys being counted in a given workspace to just the deploys that apply to a specific team.
Lead Time for Changes
Issue Cycle Time - Fallback option
Use this option if you don’t have a build tool connected or don’t want to set up webhooks. This uses the average time it takes tickets to go from their first “in progress” state to their first “completed” state.
Advanced filters are available to filter out ticket types that you don’t want to be included in the average. For example, you would like to filter out subtasks and ticket types that represent non-dev work like “test cases”.
Commit to Deploy Legacy - Fallback option
This is a legacy option in case you already have the older DORA version in your platform and cannot use webhooks. If you are new to DORA in Allstacks, this method is not applicable.
This is the classic Dora lead time which measures the average time from commit to deploy. This looks at all the commits that are included in a deploy, measures the time between when each commit was made and when the deploy succeeded, and averages those times.
Commit to Deploy Webhooks - Recommended option
This uses webhooks to enable you to report directly to Allstacks whenever you deploy to production. This allows Allstacks to support whatever tools or processes you are using for deploying without us having to build new integrations.
This enables the classic Dora lead time which measures the average time from commit to deploy. This looks at all the commits that are included in a deploy, measures the time between when each commit was made and when the deploy succeeded, and averages those times.
Time to Restore Service
Issue Lead Time
This measures time from creation to completion for tickets that meet the filter definition for “change failures”.
Advanced filters are used to define what type of tickets represent “failures” to you. For example, this might be P1s and P2s where the “caused in release” field is not empty.
Change Failure Rate
Incident Creation Count - Fallback option
Use this only if you deploy very infrequently, or if Allstacks doesn’t have access to your builds, or don’t want to use webhooks. This simply displays a count of failures rather than calculating a rate.
Advanced filters are used to define what type of tickets represent “failures” to the customer. For example, this might be P1s and P2s where the “caused in release” field is not empty.
Incident Creation/Deploys - Recommended option
If webhooks are selected for deploy frequency, the number of deploys reported via webhooks will be used for the denominator of change failure rate.
As with the Incident Creation Count method, advanced filters are used to define what type of tickets represent “failures” to the customer.
Webhooks
To use the webhooks method, navigate to the webhooks configuration page.