Code Changes Detection

CD Visibility is not available in the selected site () at this time.

Join the Preview!

CD Visibility is in Preview. If you're interested in this feature, complete the form to request access.

Request Access

Overview

Code Changes Detection allows Datadog to identify the commits introduced as part of a deployment. This is particularly valuable to:

  • Understand where specific changes have been deployed, such as tracking when updates reach the production environment.
  • Diagnose incidents related to a deployment by providing visibility into the exact changes introduced. This helps teams quickly pinpoint potential root causes and accelerate troubleshooting.

To detect the code changes deployed, Datadog runs the git log between the current deployment commit SHA and the previous deployment commit SHA. Merge commits are excluded from the computation.

The deployed code changes are visible inside any deployment execution of the Deployment Executions page. The Code Changes tab shows the previous deployment taken into consideration, and the code changes detected between the two.

Code Changes tab for changes detection feature

Additionally, the Deployments column of the Recent Code Changes page displays the service and environment details for all deployments that included a specific commit. This view provides a quick way to understand if and where your code changes are deployed. Hovering over the service value reveals whether the deployment has reached all expected environments, based on where the service is typically deployed.

Showing deployments in Recent Code Changes page

Code changes are only detected for deployments that:

  • Have a service (@deployment.service) with file path specs defined in Software Catalog (see the setup instructions for more information).
  • Have an environment (@deployment.env).
  • Have a repository URL (@deployment.git.repository_url) and a commit SHA (@deployment.git.commit.sha).

Setup

To allow Code Changes Detection on your deployments, two steps are required:

  1. Synchronize your repository metadata to Datadog.
  2. Specify the source code file path for your services.

Synchronize repository metadata to Datadog

    GitHub workflows running the pull_request trigger are not supported by the GitHub integration. If you are using the pull_request trigger, use the alternative method.

    If the GitHub integration is not already installed, install it on the GitHub integration tile.

    When configuring the GitHub App:

    1. Select at least Read repository permissions for Contents and Pull Requests.
    2. Subscribe at least to Push, PullRequest and PullRequestReview events.

    To confirm that the setup is valid, select your GitHub App in the GitHub integration tile and verify that, in the Datadog Features table, the Pull Request Information feature is marked as valid.

    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. When 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 changes are not detected.

    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.

    Specify service file path patterns

    To correctly understand the code changes that a deployment has introduced, only the commits affecting the specific service being deployed should be considered.

    This can be done in Software Catalog by specifying, for the interested services, the source code glob file path patterns in the service definition.

    If the service definition contains a full GitHub URL to the application folder, a single path pattern is automatically used.

    Example (schema version v2.2):

    links:
  - name: shopist
    type: repo
    provider: github
    url: https://github.com/organization/example-repository/tree/main/src/apps/shopist

    Code Changes Detection for deployments of the shopist service will only consider the Git commits that include changes within the src/apps/shopist/** path. You can configure more granular control of the filtering with extensions[datadoghq.com/cd-visibility].

    Example (schema version v2.2):

    extensions:
  datadoghq.com/cd-visibility:
    source_patterns:
      - src/apps/shopist/**
      - src/libs/utils/**

    Code Changes Detection for deployments of the shopist service will only consider the Git commits that include changes within the src/apps/shopist/** or the src/libs/utils/** paths.

    If both entries are defined for a service, only extensions[datadoghq.com/cd-visibility] is considered when filtering the commits.

    Further Reading

    Additional helpful documentation, links, and articles:

    Learn about Deployment VisibilityDOCUMENTATION more more Learn how to query and visualize deploymentsDOCUMENTATION more more