How often do you deploy code to production or release it to end users? Integrate your CI checks to GitHub to get transparency into your deployments on Swarmia.
How often do you deploy code to production? How many of these the production deploys fail? How long does it take to get changes into production after merging reviewed code? Are you deploying code steadily?
Deployment frequency is one of the DevOps Research and Assessment (DORA) metrics used to indicate the performance of a software development team. Ultimately, deploys are what make any work visible all the way to the user – or what makes it possible for your work to deliver a business impact.
According to the authors of Accelerate, “elite” teams are able to deploy new code on-demand or multiple times per day, whereas the release frequency of high-performing teams is between once per day and once per week.
A low deployment frequency can be an indication of working with large batches, or a signal other problems such as poor deployment infrastructure or lack of reliable automated tests.
The Deployment Insights uses Check Runs from GitHub's Checks API as the input data. This means that in order to surface the deployment data on Swarmia, you'll need to ensure that your CI (Continuous Integration) system is properly configured to pass the Checks data to GitHub.
⚠️ Note: You're likely going to need administrative permissions for any GitHub repository when integrating a CI system to use GitHub checks.
Luckily, most modern CI systems offer a productized means of passing this data to GitHub. There are a lot of CI apps directly available on GitHub's marketplace, which means this is likely the best place to start.
Custom implementations can also be created via GitHub's webhooks, which can be configured to exclusively listen to push and PR creation events.
When your CI system of choice has a GitHub app, you'll need to enable each repository to use the said app in the repository settings (Repository > Settings > Integrations).
Connecting your CI checks to GitHub
Please refer to your CI provider's documentation to integrate the Check Run data. Below, we go through a high-level overview of some commonly used systems.
For CircleCI, GitHub Checks are enabled on the CircleCI interface. You'll want to ensure you have the CircleCI app installed for the GitHub project, the repository configured to use the app, and sufficient access rights both on CircleCI project and the GitHub repository.
- You must be using the cloud-hosted version of CircleCI.
- Your CircleCI project must be using Workflows.
- You must be an Admin on your GitHub repository to authorize installation of the CircleCI Checks integration.
TravisCI has a GitHub app which can be found from the Marketplace. You'll want to start by installing the app and configuring the app for the GitHub repository (Settings > Integrations).
For Atlassian's Bamboo server, there's an addon for passing the Check Run data to GitHub. If your version is not compatible with the addon, you'll need to create a GitHub App to get in order to have API access to create check runs via the Checks API.
Once the Check Runs are configured on GitHub, seeing the data on Swarmia is simply a matter of configuring which check runs to use with each code repository. This is done on the repository settings.
When configuring the deployments, you should look for a Check Run that best describes a production deploy. The reason for this is that you want to be able to measure the frequency of code being released successfully to real users.