DORA
      Back to home
      1. Help Center
      2. Using Swarmia
      3. DORA

      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 deployments

      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)

      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

        Merged pull requests GitHub Checks

      GitHub Deployments

      		 Deployments API
      DORA metrics        
      Deployment Frequency ✅ ✅ ✅ ✅
      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 ❌ ❌ ✅ ✅

      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.

      Screenshot of GitHub checks list with a successful "Deploy Production" check.
      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).

      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.