A beginner’s guide to CI/CD and automation on GitHub

The first time I saw a CI/CD pipeline in action was a real wake-up moment. I was working at a company that used GitHub Actions to cut its release times down to five minutes. And if any issues cropped up, you could roll back a release with the touch of a button.

At that time, I had just finished a stint at a startup where the release process was far more manual and far more anxiety-inducing. We were a small team and without the benefit of a CI/CD pipeline or blue-green deployments, we could only release updates when users were less likely to be on our app late at night. It was a tedious process where any degree of human error would stretch out how long it took to deploy a build.

Yet that first experience with CI/CD turned a buzzword into something tangible and impressive, fueled by automated workflows running on GitHub Actions. Now, in a funny twist, I’m working at GitHub where GitHub Actions has become a personal focus area.

So, for anyone just getting started with CI/CD and workflow automation on GitHub, I want to turn my experience of being introduced to GitHub Actions into a resource.

Let’s get started.

So, what exactly is GitHub Actions?

For the uninitiated or anyone who’s heard of it but doesn’t fully understand it, GitHub Actions is a native CI/CD tool that runs alongside your code in GitHub. In fact, you may have noticed a tab that says “Actions” in a GitHub repository at some point (hint: that’s where GitHub Actions lives).

A screenshot showing the GitHub Actions tab in a repository

Once you open this tab up for the first time, you’ll find a quick description of what GitHub Actions is and some suggested workflows for your repository. That’s where the fun starts. GitHub Actions comes with more than 13,000 pre-written and tested CI/CD workflows and pre-built automations in the GitHub Marketplace, as well as the ability to write your own workflows (or customize an existing workflow) in easy-to-use YAML files.

A screenshot of the introduction screen a developer will see the first time they open GitHub Actions in a repository

I’ll walk you through how to build your own GitHub Actions workflow later on, but I’ll leave you with this for now: A GitHub Actions workflow can be designed to respond to any webhook event on GitHub. That means you can turn any webhook on GitHub into a trigger for an automation within your CI/CD pipeline—and that includes third-party webhook events too.

The concepts behind a GitHub Actions workflow

So, we’ve talked a bit about a GitHub Actions workflow—but sometimes it’s easiest to just see one in action (pun intended):

A screenshot of an example GitHub Actions workflow

The above workflow is composed of a few different things. These include:

• Runners: A runner is a GitHub Actions server. Each runner can be hosted by GitHub or self-hosted on a localized server. GitHub-hosted runners are based on Ubuntu Linux, Windows, and macOS, which you can specify in your workflow.
• Events: Events are defined triggers that start a workflow.
• Jobs: Jobs are a set of steps that execute on the same runner.
• Steps: Steps are individual tasks that run commands in a job. These can be an action or a shell command.
• Actions: An action is a command that’s executed on a runner—as well as the core element of GitHub Actions, which is named after it.

When you put all of these concepts together, you get a workflow that might look something like this:

on:
  issues:
    types: [opened]

jobs:
  comment:
    runs-on: ubuntu-latest
    steps:
     - name: Rick Roll
      uses: TejasvOnly/random-rickroll@v1.0
      with:
        percentage: 100

(For reference, this is a fun GitHub Actions workflow you theoretically could make part of your CI/CD pipeline. It posts a GIF of Rick Astley as a comment on every new issue that’s opened in a repository, which is scientifically proven to bolster your productivity and general enjoyment. I promise.)

Common use cases for GitHub Actions (and why you should care)

In my experience, there are four common ways I use GitHub Actions (and don’t worry, I’m including links to pre-built workflows that you can drop into your repository and start using right away). These include:

GitHub Actions workflows for CI/CD

At this point, it shouldn’t surprise you to hear that a powerful and common use case for GitHub Actions revolves around CI/CD.

It’s far from the only CI/CD platform out there (and you can integrate just about any CI/CD platform into your GitHub workflow), but it’s benefits stem from its close integration with the rest of the GitHub platform—and the ability to trigger any part of a CI/CD pipeline off of any webhook on GitHub.

Here are some useful, pre-built GitHub Actions CI/CD workflows you can use to get started:

• Node.js continuous integration: This workflow will do a clean installation of node dependencies, cache and restore them, build the source code, and run tests across different versions of node to help reduce human error. While this is specific to Node.js, there are other workflows for other programming languages, and they’re all super useful.
• Run end-to-end tests on your codebase: Whether you leverage Cypress, Applitools, or Mabl to run end-to-end UI tests on your application, there’s a GitHub Actions workflow for it. Try including these GitHub Actions in your repository to trigger a test run before you merge your code to production.
• Deploy a container image to Amazon ECR: This workflow will build and push a new container image to Amazon ECR, and then will deploy a new task definition to Amazon ECS when there is a push to your default branch. Keep in mind that similar GitHub Actions exist for different platforms, such as Terraform and Google Cloud Platform.

GitHub Actions workflows for release management

Release management is a critical part of a CI/CD pipeline. Yet you can also automate your releases even without a fully baked CI/CD pipeline. Whichever path you choose, here are two really helpful GitHub Actions workflows to level-up your approach to release management:

• Rollback or delete a release if an error occurs: We’ve all been there. I’ve released new features or bug fixes that created more problems. Sometimes, I’ve even taken the production version down (it happens). This action makes initiating a rollback easy if you find any errors in your release—and that means saving time so you can get to work fixing whatever’s wrong in your build.
• Auto-publish npm packages: This action automatically publishes your npm package when you push code to a specified branch. It’s a seemingly simple thing, but I guarantee it will save you time where it counts.

GitHub Actions workflows for third-party integrations

Whether we’re talking about part of your CI/CD pipeline or part of your normal workflow, there’s a good chance you’re using more than one tool when you’re building code. Making sure all those tools integrate with one another can be one of the less fun parts of development work—but it’s an important step.

Here are two types of workflows that I find exceptionally helpful for any beginner:

• Send a notification to Slack: This action is useful to keep you updated in a communication tool you’re using often (and if you’re using Microsoft Teams, there’s an action for that too). You can use this action to inform you about releases, build failures, the CI/CD process, newly opened pull requests, and more.
• Connect your project planning board with your repository: Whether you’re using Jira, Trello, or GitHub Issues, you can leverage a number of GitHub Actions workflows to integrate them with your project. That means you can automatically trigger new issues and comments on issues when a build fails or succeeds, and the same goes for tests. This personally helps me keep track of what’s working and what’s not with automatic updates to my project planning board.

GitHub Actions workflows for community and team management

As I’ve spoken with open source maintainers and people at companies, I’ve heard time and again how time consuming maintaining an active project, team, and/or community can be. In addition to CI/CD, GitHub Actions is a great tool for automating repeatable, yet often manual tasks within an organization, as well as managing projects and teams at scale.

In that vein, here are a few useful GitHub Actions workflows that I’ve come across:

• Take Action: This simple workflow enables contributors or team members within a project to assign themselves to issues. It can also be configured to comment on an issue with preloaded content that can either explain the project’s technologies and offer guidelines—or just thank someone for taking on an issue.
• First interaction: This workflow welcomes first-time contributors to your repository with a pre-loaded message that you can set yourself. This is a great way to onboard new team members and contributors and make sure everyone has a baseline understanding of a project before they contribute to it.
• Invite Me: It may be more useful for open source communities, but I personally love this workflow. It invites collaborators to a public organization if they comment on an issue—and that puts the onus on the collaborator to receive and accept the invitation.

Pre-built starter workflows you can immediately add to your repository

Just in case the above workflows aren’t enough to keep you busy, I wanted to give you a few more. In our Starter Workflows repository, you can find a bunch of pre-built GitHub Actions that are ready to use for continuous integration, continuous deployment, code scanning, and workflow automation. Every one of these workflows has been built and tested by the GitHub team—and they’re updated regularly too.

One of my personal favorites is CodeQL, which brings GitHub’s static code analysis engine into your workflow to identify any known security vulnerabilities in your code. Also, there are plenty of other pre-built workflows for any number of things you may be working on.

Pro tip: Customize pre-built GitHub Actions workflows to fit your needs

Since there are more than 13,000 GitHub Actions in the GitHub Marketplace, there’s a good chance you won’t need to create a workflow from scratch, since one probably already exists. Yet there probably will be a few times where you find a workflow that’s almost perfect, but needs a slight tweak to fit your needs perfectly.

In this situation, you can either create a new workflow or customize a pre-built workflow. And if you’re wondering how to customize a workflow, try reading this article I put together.

Find out how to customize a pre-built GitHub Actions workflow

Learn how to build your own GitHub Actions workflow

Sometimes it’s easier to learn by watching someone else do something in real-time. So, if you’re trying to build your own GitHub Actions workflow, watch this video to learn how to build your own action in less than 10 minutes.

Additional resources

• [Resources] A complete guide to GitHub Actions
• [Blog] How to build a CI/CD pipeline with GitHub Actions
• [Blog] 5 automations every developer should be running

Written by

Rizel Scarlett

@blackgirlbytes