Cette page n'est pas encore disponible en français, sa traduction est en cours. Si vous avez des questions ou des retours sur notre projet de traduction actuel, n'hésitez pas à nous contacter.
DORA Metrics is not available in the selected site (US1) at this time.
datadog-ci CLI / API is enabled as a Deployments event data source in DORA settings.
The following attributes are required:
started_at: The time the deployment started.
finished_at: The time the deployment finished.
service: The service that was deployed. If the provided service is registered in the Software Catalog with metadata set up (see Adding Metadata), the team of the service is automatically retrieved and associated with all metrics.
You can optionally add the following attributes to the deployment events:
repository_url: The source code repository of the service. Required for calculating change lead time.
commit_sha: The SHA of the HEAD commit associated with the deployment. Required for calculating change lead time.
team: Associate a deployment with a different team than the one found automatically for the service.
env: Filter your DORA metrics by environment on the DORA Metrics page.
id: Identify a deployment. This attribute is user-generated; when not provided, the endpoint returns a Datadog-generated UUID.
The deployment finish time is automatically set to now if --finished-at is not provided.
If the deployment CI job is running on the exact same Git revision that is being deployed, git-repository-url and git-commit-sha can be omitted and are automatically inferred from the CI context.
The --skip-git option can be provided to disable sending the repository URL and commit SHA. When this option is added, the Change Lead Time metric becomes unavailable.
For a single Git commit, change lead time (CLT) is calculated as time from the creation of the commit to when the deployment including that commit was executed.
To calculate change lead time for a deployment, Datadog runs git log between the deployment commit SHA and the previous deployment commit SHA to find all the commits being deployed. Then, it computes the average of the related change lead time values for all these commits. Datadog doesn’t store the actual content of files in your repository, only Git commit and tree objects.
For deployments identified through APM Deployment Tracking, the change lead time of a commit is computed from the time of commit creation to when that commit is first seen in a new version. It means that the Deploy Time metric is not available.
For service deployments tracked by APM to contribute to change lead time, ensure the following:
Your repository metadata is synchronized to Datadog through the GitHub integration or by the datadog-ci git-metadata upload command.
For service deployments tracked by the DORA Metrics API or the datadog-ci dora deployment command to contribute to change lead time, ensure the following:
GitHub workflows running on pull_request trigger are not currently supported by the GitHub integration.
If you are using the pull_request trigger, use the alternative method.
Select at least Read repository permissions for Contents and Pull Requests.
Subscribe at least to Push, PullRequest and PullRequestReview events.
To confirm that the setup is valid, select your GitHub application in the GitHub integration tile and verify that the Datadog Features table shows Pull Request Information meets all requirements.
Datadog's GitLab integration is in Preview. To request access to Datadog's GitLab integration for your organization, reach out to Datadog Support.
Note: The scope of the service account’s personal access token needs to be at least read_api.
You can upload your Git repository metadata with the datadog-ci git-metadata upload command.
When this command is executed, Datadog receives the repository URL, the commit SHA of the current branch, and a list of tracked file paths.
Run this command in CI for every new commit. If a deployment is executed for a specific commit SHA, ensure that the datadog-ci git-metadata upload command is run for that commit before the deployment event is sent.
Do not provide the --no-gitsync option to the datadog-ci git-metadata upload command.
When that option is included, the commit information is not sent to Datadog and the change lead time metric is not calculated.
You can validate the correct setup of the command by checking the command output. An example of a correct output is:
Reporting commit 007f7f466e035b052415134600ea899693e7bb34 from repository git@github.com:organization/example-repository.git.
180 tracked file paths will be reported.
✅ Handled in 0.077 seconds.
If the source code of multiple services is present in the same repository, further actions are needed to ensure that the change lead time is calculated by taking into account only the commits affecting the specific service being deployed.
To filter the commits measured to only the ones that affect the service, specify the source code glob file path patterns in the service definition.
If the service definition contains a full GitHub or GitLab URL to the application folder, a single path pattern is automatically used. The link type must be repo and the link name must be either “Source” or the name of the service (shopist in the examples below).
DORA Metrics for the shopist service only consider the Git commits that include changes within src/apps/shopist/**. You can configure more granular control of the filtering with extensions[datadoghq.com/dora-metrics].
Change failure rate is calculated by dividing the number of failure events over the number of deployment events for the same services and/or teams associated to both a failure and a deployment event.
