Skip to main content

Demo

How it works

Deployments track when a version of an application is deployed to an environment. Each deployment records the version, commit hash, environment, and linked pull requests. Filter deployments by application, environment, and date range to find exactly what you need.

Change type

Sweetr automatically determines the change type for each deployment by comparing commits against the previous deployment:
  • Forward: A standard deployment with new changes.
  • Rollback: The deployment reverts to a previous version.
  • No Change: A redeployment of the same version.

Deployment triggers

Deployments can be tracked through two different triggers:

API Webhook

Send deployments via the POST /v1/deployments REST endpoint. Best for custom CI/CD pipelines.

Pull Request Merge

Automatically create a deployment when a pull request is merged to a target branch. Best for trunk-based development.

Linking Pull Requests

Each deployment is automatically linked to the pull requests it contains. The linking strategy depends on the deployment trigger.

API Webhook

When a deployment is received via the API, Sweetr compares the deployment’s commit hash against the previous deployment’s commit hash using GitHub’s compare API. All merged pull requests whose merge commit falls within that range are linked to the deployment. For monorepo applications with a configured subdirectory, only pull requests that modified files within that subdirectory are linked.
The first deployment for an application/environment pair is marked as a baseline and has no linked pull requests, since there is no previous deployment to compare against.

Pull Request Merge

When a deployment is triggered by a pull request merge, the linked pull request is always the one that was merged. No commit comparison is needed.

Data quality

The deployment trigger you choose affects the accuracy of your DORA metrics, specifically Change Lead Time and Deployment Frequency.

API Webhook

Records the actual deployment time as reported by your CI/CD pipeline. This provides the most accurate time-to-deploy calculations since it captures the real moment your code reaches production.

Pull Request Merge

Uses the merge time as the deployment time. This is an approximation, since the actual deployment typically happens after the merge — once your CI/CD pipeline finishes building, testing, and deploying.
For the most accurate metrics, prefer using the API Webhook trigger so that Sweetr captures when your code was actually deployed, not just when it was merged.

Archiving

Deployments that are no longer relevant can be archived. Archived deployments are excluded from metrics. You can unarchive them at any time.