From Manual Deployment to Automated CI/CD with GitHub Actions

There was a time when deploying a web application was a lot more manual than it needed to be. You would finish your changes, run a build locally, push the project to the server, restart the application, and then wait to see if something broke in production.

If the build failed, you discovered it after deployment. If an important feature stopped working, you discovered it after deployment. And if something went wrong only in the production environment, you had another problem to debug.

Today, we can move most of this process into an automated pipeline using CI/CD. Instead of manually checking whether the application is ready to deploy, we can define a workflow and let GitHub automatically build, test, and deploy the project.

1. The Old Way of Deploying

Imagine you are working on a Next.js application. You finish a feature, run npm run build locally, and everything looks fine. You then push the changes, connect to your server, pull the latest code, install dependencies if necessary, build the application, and restart the process.

The problem is that your local environment and production environment are not always identical. A build that works on your machine does not automatically guarantee that the production deployment will work.

This workflow can become especially risky when a project grows and multiple developers are working on it.

2. The Problem With Manual Deployments

Manual deployments create several points where human error can happen. Someone can forget to run a test, deploy the wrong branch, miss an environment variable, skip a migration, or simply overlook a failing feature.

The larger the project becomes, the harder it is to rely on memory and manual checklists.

This is where automation becomes valuable. Instead of asking every developer to remember the same sequence of commands, we can define the process once and execute it consistently.

3. What Is CI/CD?

CI stands for Continuous Integration. The idea is to automatically validate code changes by running checks such as linting, type checking, automated tests, and builds whenever changes are pushed or submitted through a pull request.

CD stands for Continuous Delivery or Continuous Deployment, depending on the workflow. The general idea is to automate the process of preparing and releasing software after the required checks have passed.

GitHub Actions provides a platform for building these automated CI/CD workflows directly inside a GitHub repository.

4. Enter GitHub Actions

GitHub Actions allows you to define automated workflows using YAML files inside the .github/workflows directory of your repository. These workflows can run when specific events happen, such as a push, a pull request, a release, or a scheduled time.

name: CI

on:
  pull_request:
    branches:
      - main

jobs:
  validate:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v6

      - name: Setup Node.js
        uses: actions/setup-node@v7
        with:
          node-version: 24

      - name: Install dependencies
        run: npm ci

      - name: Type check
        run: npx tsc --noEmit

      - name: Build
        run: npm run build

This is a simplified example, but the concept is powerful: instead of manually running these commands every time, GitHub can execute them automatically inside a clean runner environment.

5. What Exactly Is a Workflow?

A GitHub Actions workflow is an automated process made up of jobs and steps. You define what event should trigger the workflow, which environment should run it, and what commands or reusable actions should be executed.

For example, a workflow can be triggered whenever someone opens a pull request against the main branch. It can then install dependencies, run linting, perform TypeScript checks, execute automated tests, and build the application.

6. Automated Testing Before Deployment

One of the biggest benefits of CI/CD is that testing becomes part of the development process instead of something you remember to do before deployment.

You can run unit tests, integration tests, end-to-end tests, type checking, linting, and production builds automatically. If one of the required checks fails, the workflow can stop before the deployment stage.

7. Where Does TestSprite Fit In?

This is where tools such as TestSprite can become useful. Instead of relying only on manual testing, you can integrate automated testing into your CI/CD workflow and run those checks as part of the pipeline.

TestSprite provides integrations designed to run automated testing within development workflows, including GitHub Actions. This means your pipeline can validate the application before allowing the release process to continue.

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v6

      - name: Install dependencies
        run: npm ci

      - name: Run automated tests
        run: npm test

      - name: Build application
        run: npm run build

The exact TestSprite configuration depends on the project and integration you are using, but the principle stays the same: automated validation becomes one of the gates that code needs to pass before reaching production.

8. Build Before Deployment

A production build is another important checkpoint. For a Next.js application, running the production build inside CI can catch problems that may not appear during local development.

A typical pipeline might run the following sequence:

Install dependencies
        ↓
Lint
        ↓
TypeScript check
        ↓
Automated tests
        ↓
Production build
        ↓
Deploy

If the build fails, the deployment job should not continue. This gives you an important safety boundary between code changes and production.

9. Blocking Bad Code From Reaching Production

There is an important distinction here: GitHub Actions itself does not magically prevent someone from pushing code to a repository. Instead, you can configure workflows and branch protection rules so that required checks must pass before a pull request can be merged into the protected main branch.

For example, you can require the CI workflow to pass before merging a pull request. If TypeScript fails, tests fail, or the production build fails, the pull request remains blocked until the issue is fixed.

10. Automatic Deployment

Once all required checks pass, the workflow can move to the deployment stage. GitHub Actions can deploy applications to different hosting providers and servers using deployment-specific actions, scripts, APIs, or SSH-based workflows.

You can also separate environments such as development, staging, and production. This makes it possible to test changes in one environment before releasing them to real users.

Pull Request
      ↓
CI Checks
      ↓
      ❌ Failed
      ↓
Fix code

      OR

      ✅ Passed
      ↓
Merge to main
      ↓
Production Build
      ↓
Deploy
      ↓
Production

11. A Practical CI/CD Workflow

For a modern web application, a practical workflow could look like this:

Developer
   ↓
Create feature branch
   ↓
Open Pull Request
   ↓
GitHub Actions
   ↓
Install dependencies
   ↓
Lint
   ↓
TypeScript check
   ↓
Automated tests / TestSprite
   ↓
Production build
   ↓
      ❌ Failed → Fix the issue
      │
      ✅ Passed
           ↓
       Merge to main
           ↓
      Deployment workflow
           ↓
        Production

This workflow creates a clear separation between writing code, validating code, and releasing code.

12. What Happens When Something Fails?

This is actually one of the best parts of the system. Failure becomes visible before the code reaches production.

Imagine you accidentally introduce a TypeScript error. The CI workflow runs and fails at the type-checking step. The deployment job never runs. You fix the error, push the change, and the workflow runs again.

The same idea applies to automated tests and production builds. Instead of discovering the problem after deployment, you discover it during the validation stage.

13. Why This Workflow Matters

The biggest advantage is not simply saving a few commands. It is consistency.

Every change can go through the same validation process. Every developer follows the same rules. Every deployment can follow the same sequence. And when something fails, you have logs showing exactly which step failed.

As projects grow, this consistency becomes increasingly valuable.

14. Final Thoughts

Manual deployment is not inherently wrong. For a small personal project, manually deploying an application can be perfectly reasonable. The problem starts when the project becomes important enough that one forgotten step can cause downtime, broken features, or a bad release.

CI/CD gives you a way to turn deployment from a manual checklist into an automated process. GitHub Actions can run your validation steps, automated testing tools such as TestSprite can become part of the testing stage, and successful workflows can continue into deployment.

The result is not a guarantee that your application is 100% bug-free. No CI/CD pipeline can provide that guarantee. What it does give you is a repeatable safety net that catches many classes of problems before they reach production.

15. Sources

1. GitHub Docs — Quickstart for GitHub Actions: official documentation explaining how GitHub Actions can automate build, test, and deployment workflows.

2. GitHub Docs — Workflows: explains workflow files, triggers, jobs, steps, and the .github/workflows directory.

3. GitHub Docs — Continuous Deployment: explains how GitHub Actions can build and test software before deployment.

4. TestSprite Documentation — GitHub Integration: documentation for integrating TestSprite with GitHub-based development workflows and CI/CD.