Better CI/CD with GitHub Actions and deployment tracking

By Sean Chapman | Posted Aug 24, 2023 | 9 min. (1769 words)

Understanding the impact of each of your deployments is crucial, especially as they become increasingly frequent. Chances are, your team is either aiming to increase shipping velocity or has already started deploying “continuously” (which is to say, multiple times a day). The biggest tech teams at the likes of Amazon and Google deploy thousands of times daily, and Atlassian has found that 75% of enterprise DevOps teams call deployment frequency their most important success criteria. And while CD comes with a host of well-established benefits, it also introduces a heightened risk of introducing new errors and issues.

Today, we’re taking a look at the state of continuous deployment according to survey data, so you can see how you stack up compared to other teams. We’re also looking at deployment tracking as a way to track and reduce errors and regressions with each new release, and introduce an elegant automation solution by combining GitHub Actions with deployment tracking via the Raygun API.

The state of continuous deployment

If you feel like your CI/CD processes could be better, you’re far from alone. We pieced together some interesting numbers from a few major surveys on how developers are doing with their CI/CD aspirations: here’s an overview of the industry as a whole.

CI/CD adoption and practices:

  • 47% of developers use either continuous integration or deployment. [State of CD]
  • Only 20% are combining CI and CD approaches to automate building, testing, and deployment to production. [State of CD]
  • 16% of developers have a lead time for code changes of less than one day. [State of CD]

Deployment frequency and speed:

  • Deployment frequency metrics vary: 33% deploy code less than once per month, while 11% deploy multiple times per day. [State of CD]
  • On the other hand, Gitlab data says 27% of teams deploy multiple times a day, 14% deploy once a day, and 29% deploy every few days. [Gitlab]
  • 60% of developers are releasing code faster than before. How much faster?
    • 35% said they’re releasing code twice as fast
    • 15% are releasing code between three and five times faster,
    • 8% said the code is flying out the door more than five times faster. [Gitlab]

Correlations between velocity, stability, and delivery:

  • Speed and stability are correlated: 50% of developers who take 30 days or more to commit code changes also perform poorly in restoring service, taking one week+. [State of CD]
  • 90% of high performers in software delivery speed are high performers in stability. [State of CD]
  • 1/3 top performers in lead time for code changes also excel in time to restore service. [State of CD]

DevOps adoption and challenges:

  • Feature flagging is associated with high deployment frequency, and there’s a strong correlation between the adoption of DevOps technologies and performing well in lead time for code changes, deployment frequency, and time to restore service. [State of CD]
  • Only 4% of companies consider themselves experts in CI/CD. While teams say they want to be deploying multiple times a day, only 5% are achieving that, and for 69% the actual time to deploy a single CI/CD pipeline is days or weeks. [Cloudbolt]
  • 63% say there are too many manual processes involved, 56% say they have no automated processes for post-deployment activities, 55% say it’s difficult to create consistent CI/CD pipeline environments across different development teams, 53% say it’s challenging to proactively detect infrastructure issues. [Cloudbolt]

overview of development activities

State of CD

Automation and improvement priorities:

  • 47% of teams have full test automation (this nearly doubled from 2021-2022) [Gitlab]
  • 24% of teams say their software development life cycle is fully automated [Gitlab]

How deployment tracking helps you go faster

So now that you know where you stand, let’s look at what you can do to achieve your loftiest CI/CD goals.

Every deployment, whether it’s a minor bug fix or a major feature release, has the potential to introduce new issues. With continuous integration and deployment, it becomes even more critical to have accurate and granular error tracking against every change and addition. Your team must be able to gauge the impact of each release immediately, ensuring the highest quality standards in their software and iterating with confidence.

That’s where deployment tracking comes in. Tracking can help you deploy more frequently, with fast, automated feedback to swiftly pinpoint whether a release has inadvertently introduced new bugs or if a previously implemented bug fix has been effective.

Deployment trackers provide information about upcoming deployments, notify organizations when new deployments ship, and display the entire deployment history on a timeline. These metrics are useful for a range of teams and players throughout your organization.

Perhaps most importantly, deployment tracking helps with damage control. If there’s a problem in the wake of a new release, you can pinpoint it rapidly and roll it back, repair it, or freeze production while fixing the problem.

Here’s how Skimmer uses Deployment Tracking:

“We did a deployment this morning, and the first thing I did was look at Raygun… And I just look at incoming exceptions and see… Okay, our software’s not perfect. We have exceptions. Are the exceptions, are they different? Is the volume higher, or maybe lower even, post-deployment? And are there any new notable exceptions that seem like we could have had a regression or we introduced some sort of problem?

“When I was looking today, I saw something that I thought was a small issue, but by looking at the “users affected” metric in Raygun, I could see that it was a widespread issue.”

You should be using GitHub Actions

GitHub Actions is a powerful automation tool provided by GitHub, and built and maintained by the GitHub community. Actions allow developers to automate workflows, from CI/CD processes to custom notifications, directly within their repositories, so you can build, test, and deploy your code right from GitHub. You can configure Actions to automate your most used GitHub events like push, issue creation, or a new release and combine actions for the services you use.

In the Raygun engineering team, we thought that Action sounded like a darn good candidate to integrate with our existing Deployment Tracking feature, which exists to make it easier for developers to correlate deployments with software errors. So, we’ve created an integration between the Raygun Deployments API V3 and the Raygun Deployments GitHub Action to make this process even more streamlined.

By using Deployment Tracking via the Raygun API, combined with an Action in GitHub, notifying Raygun of a new deployment becomes a seamless part of your CI/CD pipeline.

We dive into how that works below.

Setting up Raygun Deployment Tracking with GitHub Actions

Create a Personal Access Token

  1. Log into Raygun
  2. Click on your profile in the top right
  3. Head to My Settings > Personal Access Tokens
  4. Click “Create new token” and ensure the deployments:write scope is selected
  5. Keep a copy of the token value after creation, this will be required later in the process.

Tip: Assign a descriptive name to the token and restrict the scopes to only the essentials.

For an in-depth understanding of Personal Access Tokens, refer to the Raygun documentation.

Integrate the Raygun Deployments Action into your workflow

GitHub Workflows are defined as a YAML file located in the .github/workflows directory of your repository. A workflow can be customized to have many triggers and steps specific to your use case.

To learn more about creating and managing workflows, head over to GitHub’s documentation.

The following code snippet can be added to an existing workflow. This will add the Raygun Deployments Action and notify Raygun of a deployment each time that workflow is executed.

- name: Run Raygun Deployment Action
  uses: MindscapeHQ/raygun-deployments-action@v1
  with:
    personal-access-token: ${{ secrets.RAYGUN_PAT }}
    api-key: ${{ secrets.RAYGUN_API_KEY }}
    version: '1.0.0'
    comment: 'Created a new deployment!'

In this example, we leverage GitHub’s built-in support for encrypted secrets. Secrets should be used to store any sensitive information, such as passwords, api keys, and tokens, without committing them to source code.

Secrets Explained:

  • RAYGUN_PAT - your personal access token, providing secure access to our API
  • RAYGUN_API_KEY - the API Key for the application in which you’d like to track deployments

We also recommend setting the version and comment to something meaningful to your application. Example values could be the commit short SHA for version, and the commit message for the comment. It’s important the version matches the application version in your Crash Reporting provider, as this enables deployments to be correlated with errors. Examples of how to add versions to errors can be found in our documentation, for example JavaScript.

Here’s a comprehensive example of a GitHub workflow that creates a deployment in Raygun on every push to the main branch.

on:
  push:
    branches: 
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Generate the short SHA for the current commit
        id: vars
        run: echo "sha_short=$(git rev-parse --short HEAD)" >> $GITHUB_OUTPUT
      - name: Create Raygun Deployment
        id: create_deployment
        uses: MindscapeHQ/raygun-deployments-action@v1
        with:
          personal-access-token: ${{ secrets.RAYGUN_PAT }}
          api-key: ${{ secrets.RAYGUN_API_KEY }}
          version: ${{ steps.vars.outputs.sha_short }}
          comment: ${{ github.event.head_commit.message }}
      - run: echo "🎉 Deployment [${{ steps.create_deployment.outputs.deploymentId }}] was created successfully."

For more detailed information on creating and using GitHub Actions see their documentation.

Automate and monitor

Once integrated, each time your workflow is triggered (e.g., on every push to the main branch), the Raygun Deployments Action will automatically notify Raygun of the deployment. This allows you to monitor the health of your application post-deployment and quickly identify any issues.

Wrap-up

In this article, we’ve explored the current state of CI/CD and hopefully helped you see where you stand in relation to the industry at large. We’ve also talked about where deployment tracking fits into your Continuous Delivery efforts, and shared the value of Raygun Deployment Tracking and its integration into your GitHub workflow using the Raygun Deployments Action.

While I’m obviously biased as a member of the Raygun team, I’d strongly recommend instituting some kind of deployment tracking solution, even if it’s not ours! Too many times I’ve been on the receiving end of a phone call in the middle of the night because a critical function has been impacted by a recent release. The ability to track newly occurring errors in deployments, and have those errors raise alerts, is something I’ll personally never be without again.

The combination of Deployment Tracking and GitHub Actions offers a powerful solution for developers to stay on top of their application’s health and confidently maintain an elite-level deployment velocity. By automating deployment notifications, teams can focus on what they do best: building amazing software!

Dig into GitHub Actions in their documentation here, and feel free to grab a 14-day trial of Raygun here. Built by developers, for developers!