DORA metrics measured by GitLab
Track deployment frequency
There are two ways to track your deployments:
- Use a CI/CD job for deployment.
- Create a deployment record using the API.
The API approach is generally used when you cannot link GitLab to your deployment environment.
Once you have configured tracking for your deployment frequency, the next step is to measure the time it takes for a code change to get into production.
Measure lead time for changes
Lead time for changes is the amount of time it takes for a code change to get into production. This is measured using Merge Requests.
This assumes that you don’t commit changes directly into the branch that affects deployment to the production environment. If you commit directly to the production branch, there won’t be any logical endpoint to track the lead time.
Measure change failure rate and time to restore service
You can track the following using GitLab incidents.
- Change failure rate: Measures how often a change causes a failure in production.
- Time to restore service: Measures the time it takes to recover from a failure in production.
- GitLab assumes all incidents created pertain to the production tier. If you create incidents to track your staging or development environments, the metrics may not be accurate.
- Incidents can be created both manually and automatically.
- For more information, refer to:
-
GitLab documentation on incidents.
-
GitLab documentation on creating an incident.
DORA metrics calculation
- GitLab calculates DORA metrics based on deployments to production environments.
- To ensure GitLab correctly recognises your production environments, tag the environments “production” or “prod”.
Caveats and challenges
- Data Latency: There might be a slight delay in DORA metrics due to manual or delayed data population.
- Data Location: GitLab’s DORA calculation requires data to be within GitLab.
- Third-party Integrations: While direct integration with tools such as Jira isn’t currently available, we’re actively exploring solutions to bridge this gap and streamline your workflow.
- Network Segregation: Networks with segregated systems may require custom workflows and/or middleware to ensure accurate data population (e.g., deployment data).
Next steps
Additional resources
For more information, refer to GitLab documentation.
For more details on how various metrics are calculated, refer to GitLab’s DORA Metrics documentation.