DEV Community

Cover image for How to Set Up a CI/CD Pipeline Using GitHub Actions
Emmanuel Mumba
Emmanuel Mumba

Posted on • Originally published at deepdocs.dev

How to Set Up a CI/CD Pipeline Using GitHub Actions

When I first started working with teams, I quickly I learned that writing code was the easy part, getting it into production without breaking things was the real challenge. That’s where I discovered the power of CI/CD.

A CI/CD pipeline is essentially an automation that makes sure every commit goes through the same checks, builds, and deployments, which means fewer late-night bug fixes and broken builds.

Done right, it removes the pain of manual releases and makes your team move faster. But if you’ve ever tried setting up tools like Jenkins or GitLab CI, you probably know the learning curve can be… a bit much.

That’s why I’ve come to really appreciate GitHub Actions. Since most of my projects already live on GitHub, I don’t need to jump between platforms or wire up external services. It’s all in one place. Setting up a working CI/CD pipeline is a lot easier than I expected.

In this article, I’ll walk you through how I set up a CI/CD pipeline with GitHub Actions, using a sample React app and deploying it to GitHub Pages. Along the way, I’ll share some lessons I’ve learned, and by the end, you’ll see how to get your own project running with automated builds and deployments.

If you’re new to CI/CD concepts, you may want to first check out our earlier article CI/CD in DevOps: Theory to Practice where we dive into the principles. Here, we’ll stay practical and hands-on.

What is CI/CD? (Quick Refresher)

Before setting up the pipeline, let’s recap the three core concepts:

Continuous Integration (CI)

In a collaborative environment, multiple developers work on separate features. Once completed, each feature is merged into the shared repository. With CI, every merge triggers automated builds and tests to catch bugs early.

Continuous Delivery (CD)

This goes a step further - once the code passes all tests, it’s automatically built and deployed to a staging environment, making it ready for production release.

Continuous Deployment (CD)

The final stage automates deployment to production. Every successful commit moves straight into the live environment, ensuring users always experience the latest stable version.

GitHub Actions — The CI/CD Platform

GitHub Actions is GitHub’s own automation platform. Instead of installing a separate CI/CD system, you define workflows inside your repository. These workflows are written in YAML and specify jobs that run on GitHub-hosted virtual machines (like Ubuntu, Windows, or macOS).

A typical workflow might include steps like:

  • Checking out code
  • Installing dependencies
  • Running tests
  • Building the app
  • Deploying to GitHub Pages, AWS, or another service

What makes GitHub Actions powerful is its marketplace of prebuilt actions you don’t need to reinvent the wheel for common tasks like caching, testing, or deployment.

Setting Up the Project

For our hands-on guide, let’s assume we’re working with a small React application. (You can follow the same steps for a Node.js API, Python app, or static site with slight modifications.)

Create a new React app:

Push it to a new GitHub repository:

Now we’re ready to integrate GitHub Actions.

Setting Up GitHub Actions Workflow

A workflow in GitHub Actions is an automated process that runs one or more jobs based on events in your repository. Think of it as a blueprint that tells GitHub when to trigger automation (like on every push or pull request) and what steps to run (such as installing dependencies, running tests, or deploying your app).

Workflows live inside a .github/workflows/ directory. Let’s create one:

Inside main.yml, we’ll define the CI/CD pipeline.

Step 1: Creating a GitHub Personal Access Token

For deployment, GitHub Actions needs permission to push to your repository. To give it access:

  1. Go to GitHub > Settings > Developer Settings > Personal Access Tokens.
  2. Create a new token with repo permissions.
  3. Copy the token.
  4. In your repository, go to Settings > Secrets and variables > Actions.
  5. Add a new secret named DEPLOY_KEY and paste the token.

Step 2: Writing the Workflow (YAML)

Here’s a sample workflow for building and deploying a React app to GitHub Pages:

Step 3: Updating package.json

Add the homepage field so React knows the deployment URL:

Commit and push the changes:

Step 4: Watching the Workflow in Action

  1. Go to your GitHub repository.
  2. Click on the Actions tab.
  3. You’ll see the workflow automatically run.
  4. After success, visit https://<username>.github.io/<repo>/ to see your app live.

Now, every push to main will trigger this CI/CD pipeline.

Advanced CI/CD Features in GitHub Actions

The basic pipeline is enough to build and deploy your app, but GitHub Actions becomes truly powerful when you leverage its advanced features. These capabilities help you scale your workflows, optimize performance, and integrate CI/CD into the wider DevOps ecosystem.

1. Matrix Builds

In real-world projects, you often need to test your application against multiple environments—different Node.js versions, Python versions, or even operating systems. Instead of writing separate workflows, you can define a matrix build.

Here’s an example testing against multiple Node.js versions:

This runs the test job in parallel across Node 16, 18, and 20. If your app depends on compatibility, this is invaluable.

2. Caching Dependencies

Installing dependencies from scratch on every workflow run can be slow. GitHub Actions provides a built-in caching mechanism that speeds things up significantly by reusing dependencies across runs.

Example for caching node_modules:

This ensures that unless package-lock.json changes, npm will pull dependencies from cache instead of reinstalling everything. For large projects, this can save minutes on every build.

3. Branch Rules and Environments

Not all branches should trigger deployment. A common best practice is:

  • Run tests on feature branches
  • Deploy only when merging into main or release branches

Here’s how you can define this behavior:

With this setup:

  • Every pull request triggers tests.
  • Only commits pushed to main trigger deployments.

For production environments, you can also use GitHub Environments to require manual approvals before deploying.

4. Third-party Integrations

GitHub Actions is not limited to building and deploying code—it integrates with hundreds of external services to make your pipeline richer.

Some popular use cases:

Slack Notifications: Send messages when a workflow succeeds or fails.

Docker Builds: Build and push Docker images to Docker Hub or GitHub Container Registry.

Cloud Deployments: Deploy to AWS, Azure, or Google Cloud using official actions. For example, deploying a Lambda function on AWS:

5. Scheduled Workflows

Sometimes you need automation that isn’t triggered by code changes like running nightly tests, backups, or security scans. GitHub Actions supports cron jobs for scheduled workflows:

This example runs the job every day at 2 AM UTC.

👉 If you want to explore how documentation fits into this process, check out our article Why CI/CD Still Doesn’t Include Continuous Documentation.

Debugging GitHub Actions Pipelines

Sometimes things fail. Here are tips:

  • Check logs: Each job has detailed logs.
  • Use actions/setup-node correctly: Mismatched Node versions can break builds.
  • Verify secrets: Ensure your DEPLOY_KEY is set up properly.
  • Dry-run locally: Test builds locally before pushing.

Why GitHub Actions for CI/CD?

There are many CI/CD tools out there Jenkins, GitLab CI, CircleCI but GitHub Actions has quickly become a favorite because it brings CI/CD closer to your code.

  • Native GitHub Integration – Since your code is already on GitHub, you don’t need extra setup or webhooks. Workflows trigger directly from events like push or pull_request.
  • Free & Cost-Effective – Open-source projects get generous free minutes, and even private repos get enough to run small-to-medium pipelines without extra cost.
  • Scalable – Start simple with one workflow, then grow into complex, multi-environment pipelines with approvals and deployments.
  • Community Marketplace – Thousands of prebuilt Actions exist for tasks like AWS deployments, Slack notifications, Docker builds, and linting no need to reinvent the wheel.
  • Secure & Centralized – Secrets are managed within GitHub, and with branch protection and environment approvals, it’s production-ready.

For teams already on GitHub, this means less context switching: code, issues, pull requests, builds, and deployments all live in one place. That simplicity is what makes GitHub Actions stand out from the competition.

Conclusion

CI/CD is no longer optional it’s the standard for modern development teams. With GitHub Actions, you don’t need to juggle multiple tools or maintain complex infrastructure. You can build, test, and deploy directly from your repository.

While CI/CD pipelines are perfect for automating your builds and tests, our team at DeepDocs is working on automating another type of software artefcats, namely your documentation.

You see, updating docs is still a manual process, and it is often de-prioritised as it is seen as a boring or low value task. DeepDocs takes care of keeping your docs automatically updated with your codebase, with no additional manual effort. It is completely free to try.

In this article, We walked through setting up a CI/CD pipeline for a React app deployed on GitHub Pages, but the same workflow applies to Node.js, Python, or Dockerized apps.

If you’re just starting with DevOps pipelines, GitHub Actions is one of the most approachable ways to learn. And once you get comfortable, you’ll find it scales with you from personal projects to enterprise deployments.

Top comments (4)

Collapse
 
codeflowjo profile image
codeflowjo

Great article.

Collapse
 
aikodev profile image
Aiko Tanaka

At this point true CI/CD is the standard.

Collapse
 
a-k-0047 profile image
ak0047

Thanks for sharing. I will try it.

Collapse
 
pv_interiordesign_1983648 profile image
pv interiordesign

At this point true CI/CD is the standard.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.