Deployments
Set up deployments by creating an application and selecting your method of deployment.
Last updated
Was this helpful?
Set up deployments by creating an application and selecting your method of deployment.
Last updated
Was this helpful?
Deployments are used as the data source of Deployments Insights, which provides visibility into the frequency and quality of deployments:
Deployment frequency & total count of deployments
Change failure rate (CFR), or how often you deploy defects into production
Mean time to recovery (MTTR), the average time it takes to address defects
Navigate to
Create a new application to configure the deployments for
Configure your deployment data source (see below for source specific instructions)
Select additional production environments for the app (optional) to calculate DORA metrics.
You can use a variety of data sources for getting deployments to show on Swarmia:
Merged pull requests
GitHub Checks
GitHub Deployments
Deployments API
Deployment frequency
✅
✅
✅
✅
Time to deploy
❌
✅
✅
✅
Change lead time
❌
✅
✅
✅
Change failure rate In some cases, it's also possible to use Jira issues as a change failure source. Reach out to us to learn more.
✅
✅
✅
✅
Mean time to recovery (MTTR)
✅
✅
✅
✅
Change failure automation
Reverts
Reverts, Rollbacks
Reverts, Rollbacks
Reverts, Rollbacks, API
Multiple environments
❌
❌
✅
✅
If you're already using GitHub Deployments in your release workflow, there's no need to manually create a deployment app. Swarmia automatically tracks those, making it the preferred method for a quick start.
Most CI/CD tools have a GitHub integration that can report your deployment job status back to GitHub. If GitHub Deployments are not readily available, but your deployment status is visible in GitHub as a check, using GitHub Checks could be suitable.
These are the fastest ways to get started with Deployment insights and allows Swarmia to backfill historical data automatically. You can also later update your application from one deployment source to another without losing historical data.
We recommend using the Deployments API in the cases where:
You deploy manually.
Your CI/CD pipeline does not report deployments back to GitHub.
You need multiple environments.
You want to automate additional change failures (in addition to reverts and rollbacks).
Regardless of the data source, Swarmia doesn't currently distinguish pull requests that affect one deployed monorepo application but not the other, which can have an impact on the per-application DORA metrics.
Members can also set up production environments for individual apps in addition to these filters.
— use merges into a specific branch as the proxy for deployments
— automatically create deployments from your CI/CD pipeline based on repository, check, and branch configurations
— automatically create deployments based on GitHub Deployments
— send deployment information directly, supports multiple environments
Yes, in certain cases it's possible. If you're using Deployments API and have the historical data stored somewhere, you can send it to Swarmia and it will be shown as expected. If you're using GitHub Deployments, longer backfills are available for select Standard customers. Reach out to us at for more information.
For -style setups where multiple applications are deployed based on a single repository, GitHub Deployments or the Deployments API can be configured to represent each one via the deployment's environment. Also GitHub Check or Merged pull request based deployments can work, but need a separate Swarmia deployment configuration for each deployed application.
You can configure environments as production for your deployments. Any deployments made to the production environments will be used to calculate , and appear by default in .
Navigate to
. Leverage your environment naming conventions and set up filters to assign environments as production. You need to be an to set this up.
