How to Build a CI/CD Pipeline from Scratch

Step 1: Understand What CI/CD Actually Does

CI (Continuous Integration) means every code change is automatically verified. CD (Continuous Deployment) means verified changes ship to production without manual intervention. Together, they eliminate the "it works on my machine" problem.

A typical pipeline runs in this order:

1. Lint — Catch style and pattern issues
2. Typecheck — Catch type errors
3. Test — Catch logic errors
4. Build — Catch build-time errors
5. Deploy — Ship to production

Each step gates the next. If linting fails, you don't waste time building. If tests fail, you don't deploy broken code.

Step 2: Create Your First GitHub Actions Workflow

GitHub Actions workflows live in .github/workflows/. Create a file called ci.yml:

Key decisions:

• npm ci over npm install — it's faster and uses the exact lockfile versions
• cache: "npm" — caches ~/.npm so repeat installs are fast
• Trigger on both push and PR — catches issues before and after merge

Step 3: Add Linting and Type Checking

These are the cheapest checks. They run in seconds and catch entire categories of bugs.

Run these before tests and builds because they're fast. If you have a formatting check, add it here too:

A common mistake is running lint with auto-fix in CI. Don't. CI should detect problems, not silently fix them. Developers should fix issues locally before pushing.

Step 4: Add Tests

Tests are the core of your pipeline. They verify behavior, not just syntax.

The --ci flag (in Jest) disables interactive mode and fails on missing snapshots. The --coverage flag generates a coverage report you can use later.

For projects with different test types, split them into parallel jobs:

Parallel jobs cut your total pipeline time significantly.

Step 5: Add the Build Step

The build step catches issues that linting and typechecking miss — missing environment variables, broken imports, SSR errors.

Secrets are configured in your repository's Settings > Secrets and variables > Actions. Never hardcode them in the workflow file.

For build artifacts you might need later (like for deployment), upload them:

Step 6: Add Deployment

Deployment depends on your hosting platform. For Vercel, the simplest approach is to let Vercel's GitHub integration handle it — it deploys automatically on push. But if you want explicit control:

The needs: [ci] line ensures deployment only runs after CI passes. The if condition restricts deployment to pushes to main — pull requests get CI checks but don't deploy.

For staging environments, deploy PRs to preview URLs:

Step 7: Add Notifications and Branch Protection

A pipeline nobody checks is worthless. Set up notifications and enforce the pipeline.

Branch protection rules (Settings > Branches > Add rule):

• Require status checks to pass before merging
• Select your CI job as a required check
• Require branches to be up to date before merging
• Optionally require review approval

Notifications for failures — add a step at the end of your workflow:

The complete pipeline should take under 5 minutes for most projects. If it's slower, look for opportunities to parallelize jobs, cache dependencies, and skip unnecessary steps on draft PRs. A fast pipeline is one developers actually wait for instead of ignoring.