Deployments
Deployment tracking helps you measure the performance and efficiency of your deployment process. Several key deployment metrics (e.g. Deployment Frequency, Time to Deploy, and Batch Size) require setting a deployment method for each repository.
Our platform analyzes your Git data for relevant deployment statuses (such as successes, failures, and errors) and uses these signals to track these key metrics. While we automatically detect deployment methods for most repositories, validation is often required during setup. In some cases, you may need to manually configure the deployment method.
Supported Deployment Signals
Our platform uses signals from your Git provider to track how code gets built, tested, and deployed. Support for specific signals varies by provider:
| Git Provider | Supported Signals |
|---|---|
| GitHub | Deployments, Releases, Actions (Workflows), Tags, Status Checks (Checks, Commit Statuses) |
| Bitbucket | Deployments, Pipelines |
| GitLab | Deployments, Releases, Pipelines |
| Azure DevOps | Pipelines |
There are more details about each of these signals in the appendix.
Configuring a Deployment Method
You can configure deployments in the Settings view under the Repositories tab. After selecting a repository, you can choose from the available deployment methods detected from your Git provider.
Below are the available deployment methods. For each deploy method, you will see a list of all instances of that method.
| Method | Format | Notes |
|---|---|---|
| Run a workflow | Workflow Name | Uses the name of the workflow run or job. Example: “Deploy to production” |
| Run a check run | Check Run Name | Uses the name of a specific check run, which is typically a step within a larger workflow running in a pull request. Example: “Deploy to Netlify” |
| Run a pipeline | Pipeline Job Name | Uses the name of a specific pipeline job. Example: “Deploy to production” |
| Deploy to an environment | Environment Name | Tracks deployments to a specific environment Example: "Production" |
| Publish a release | Branch Name | Tracks deployments based on a release created from a specific branch. Example: “main” |
| Create a tag | Regex | Uses a regular expression (wildcard) to match tags. For versioned releases, you could enter "v". |
| Does not deploy | True/False | If a repository has CI processes that are auto-detected but does not deploy to production, you can turn off deployment tracking. |
[Optional] Restrict to a specific branch
By default, deployments are tracked for all branches. You can restrict tracking to a specific branch when using workflow runs, check runs, or pipeline jobs as your deployment method.
Understanding Auto-Detection
Our platform automatically detects potential deployment methods, marking them with a lightning icon in the configuration dropdown. If you do not manually set a method, we select one based on a clear ranking system.
While our platform automatically detects deployment methods, validation is typically required during setup, and in some cases, you may need to manually configure deployments for some repositories.
Here is how our auto-detection algorithm works:
- Precedence: A manual override will always take precedence over an auto-detected setting.
- Ranking: We rank successful deployment signals by type in the following order:
- Deployments
- Workflows/Pipelines
- Check Runs
- Releases
- Commit Statuses
- Git Tags
- Recency: If there are multiple signals of the same type, we prioritize the one that has run most recently.
- Filtering: We automatically filter out signals that contain obvious non-production names, such as "test" or "staging".
The auto-detected method will automatically update a deployment method changes (e.g. switching from Releases to GitHub Actions).
How Pull Requests are Linked to Deployments
Our platform uses a sophisticated matching process to associate pull requests with their corresponding deployments. Below are some of the strategies we use to match pull requests to deployments:
- Default Branch: A PR is merged to the default branch between two successive deployments.
- Git Tags: A PR contains a commit SHA that was between two successive Git tags.
- Release Branch: A PR is merged to a non-default branch (e.g. a release or deploy branch) between two successive deployments.
- Gitflow: A PR is merged to a release or hotfix branch using Gitflow.
- Hot Fix: A PR is merged directly to the deploy branch.
- Manual Release Branch: A PR contains commits found on a manual deployment branch.
How We Track Deployments
Below are important details on how our platform calculates specific metrics related to your deployment process.
Deployment Frequency
- This metric is calculated based on deployments that deliver new code.
- Deployments with no associated pull requests are not counted.
- Draft pull requests are excluded from this calculation.
- Pull requests authored by bots are included.
Deployment Success Rate
- This calculation includes all individual run attempts to provide a precise success rate.
- For example, if a workflow fails on its first attempt and then succeeds on the second, we count it as one failed deployment and one successful deployment.
Deployment Batch Size
- Batch Size is a comprehensive measure of all code changes included in a deployment.
- Unlike our standard PR Size metric, this calculation includes changes to all file types, such as manifest files, to accurately reflect the total size of the change deployed.
Appendix: More Details on Deployment Signals
GitHub Signals 🐙
- Deployments: Represents a request to deploy a specific branch, tag, or SHA. This allows external services or workflows to post deployment statuses (e.g., success, failure) back to GitHub.
- Releases: A high-level concept built on Git tags used to package and present a version of your software to users.
- Actions (Workflows): GitHub's native CI/CD platform for creating automated processes (workflows) that build, test, and deploy code.
- Status Checks: External processes that report on the status of a commit. There are two types:
- Checks: Detailed pass/fail statuses for the last commit on a branch.
- Commit Statuses: A simpler pass/fail label attached to a commit, often from an external CI/CD tool.
- Tags: A pointer to a specific commit, often used to mark a release point (e.g., v1.0).
Bitbucket Signals 🔵
- Pipelines: Bitbucket's integrated CI/CD service for automating builds, tests, and deployments.
- Deployments: A feature within Pipelines that provides visibility into the history of deployments to different environments.
GitLab Signals 🦊
- Pipelines: The core of GitLab's CI/CD functionality, composed of jobs and stages that build, test, and deploy your code.
- Deployments: A record that code was deployed to a specific environment.
- Releases: A versioned entry associated with a Git tag used to package a release.
Azure DevOps Signals 🔷
- Pipelines: The language-agnostic CI/CD platform within Azure DevOps for building, testing, and deploying applications.