Continuous integration (CI)

What continuous integration is

Continuous integration (CI) consists of integrating and verifying code frequently and automatically. Every time someone pushes changes, a server runs a series of checks to detect errors early, before they reach production.

A typical CI pipeline, in order, is:

1. Install the dependencies (npm ci).
2. Lint: check style and static errors.
3. Test: run the automated tests.
4. Build: compile/package the application.

If any step fails, the pipeline stops and the commit is marked as broken. This way nobody integrates code that doesn't compile or that breaks the tests.

GitHub Actions

GitHub Actions runs these pipelines inside the repository itself. Its vocabulary:

• Workflow: an automated process described in a YAML file inside .github/workflows/.
• Trigger (on): the event that fires the workflow (a push, a pull_request, a schedule...).
• Job: a set of steps that run on a machine (runner). Several jobs can run in parallel.
• Step: each action inside a job (run a command or use a reusable action with uses).

A CI workflow

name: CI

# Trigger: runs on every push and on every pull request
on:
  push:
    branches: [main]
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci      # install
      - run: npm run lint # lint
      - run: npm test     # test
      - run: npm run build # build

Read it top to bottom: on every push to main or on every pull_request, GitHub starts an Ubuntu runner, downloads the code (checkout), sets up Node and runs install → lint → test → build. If a run returns a non-zero exit code, the job fails and the rest does not continue.

CI is your safety net: it turns "I forgot to test it" into an automatic check that can't be skipped.