Configuring deployments in Swarmia

Set up deployments by creating an application and selecting your method of deployment.

About deployments

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

Setting up deployment apps

1. Navigate to Settings → Deployments
2. Create a new application to configure the deployments for
3. Configure your deployment data source (see below for source specific instructions)
4. Select additional production environments for the app (optional) to calculate DORA metrics.

Deployment data sources

You can use a variety of data sources for getting deployments to show on Swarmia:

• Merged pull requests — use merges into a specific branch as the proxy for deployments
• GitHub Checks — automatically create deployments from your CI/CD pipeline based on repository, check, and branch configurations
• GitHub Deployments — automatically create deployments based on GitHub Deployments
• Deployments API — send deployment information directly, supports multiple environments

Comparison of data sources

Which data source should I use?

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.

GitHub Deployments with three succeeded deployments and one failure.

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.

GitHub checks list with a successful "Deploy Production" check.

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).

Is it possible to backfill more than 90 days of deployments data?

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 hello@swarmia.com for more information.

Notes about monorepos

For monorepo-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.

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.

Configuring production environments

You can configure environments as production for your deployments. Any deployments made to the production environments will be used to calculate DORA metrics, and appear by default in Infrastructure → Deployments.

1. Navigate to Settings → Deployments
2. Configure production environments. Leverage your environment naming conventions and set up filters to assign environments as production. You need to be an admin to set this up.
   
   
3. Members can also set up production environments for individual apps in addition to these filters.