How to Set Up a CI/CD Pipeline

The Short Answer

For most modern web applications, combine GitHub Actions for testing and linting with Vercel or a similar platform for automated deployments. Push to a branch and your pipeline runs tests, checks types, lints code, and deploys a preview environment. Merge to main and it deploys to production. This setup takes under an hour and eliminates manual deployment errors permanently.

GitHub Actions: Your Testing and Quality Gate

GitHub Actions is the most widely adopted CI tool for modern development teams, and it is free for public repositories with generous free-tier minutes for private repos (2,000 minutes/month).

A solid CI workflow runs on every pull request and includes these steps:

1. Install dependencies -- Use cached node_modules to keep runs under 2 minutes. The actions/cache action with a hash of your lockfile handles this.
2. Type checking -- Run tsc --noEmit to catch TypeScript errors before they reach production.
3. Linting -- Run ESLint to enforce code standards consistently across the team.
4. Unit and integration tests -- Run your test suite with Jest, Vitest, or your framework's built-in testing tools.
5. Build verification -- Run the production build to catch build-time errors that type checking misses.

Key configuration decisions:

• Trigger on pull_request events for validation and push to main for deployment
• Use concurrency groups to cancel outdated runs when new commits are pushed to the same branch
• Set appropriate timeouts (10-15 minutes) to prevent stuck workflows from consuming your minutes
• Use matrix builds if you need to test against multiple Node.js versions

Secrets management in GitHub Actions uses encrypted environment variables. Store API keys, database URLs, and deployment tokens in repository secrets or environment-specific secrets. Never commit secrets to your repository, even in private repos.

Vercel Auto-Deploy and Preview Deployments

Vercel eliminates the need for custom deployment scripts by connecting directly to your Git repository.

How it works: Connect your GitHub repo to Vercel, and every push triggers an automatic deployment. Pushes to main deploy to production. Pushes to any other branch create a unique preview URL. Vercel posts the preview link directly as a comment on your pull request.

Preview deployments are one of the most valuable CI/CD features for teams. Product managers, designers, and QA engineers can review changes on a live URL before they merge. Each preview has its own isolated deployment with its own URL, so multiple features can be reviewed simultaneously.

Environment variables in Vercel are scoped to Production, Preview, and Development. This lets you use a staging database for preview deployments and a production database for the live site without any code changes. Configure these in the Vercel dashboard under project settings.

For applications not suited to Vercel, Docker containers with GitHub Actions provide a flexible alternative. Build your Docker image in CI, push it to a container registry, and deploy to your hosting provider (AWS ECS, Google Cloud Run, or a VPS).

Environment Management and Branch Strategy

A clean environment strategy prevents the "works on my machine" problem and staging data from leaking into production.

Three-environment model:

• Development: Local environment with local or dev-tier databases. Use .env.local files (never committed to Git).
• Staging/Preview: Automatically provisioned for each PR. Uses a staging database and test API keys. Mirrors production configuration as closely as possible.
• Production: Deployed on merge to main. Uses production secrets stored in Vercel or your CI platform.

Branch strategy for CI/CD:

• main branch is always deployable. Direct pushes are blocked; all changes go through pull requests.
• Feature branches are short-lived (1-3 days). Long-lived branches create merge conflicts and integration headaches.
• Use branch protection rules to require passing CI checks and at least one code review before merging.

Database migrations in CI/CD need special attention. Run migrations as part of your deployment pipeline, not as a separate manual step. Tools like Prisma Migrate or Drizzle Kit generate migration files that you commit and run automatically during deployment.

How UniqueSide Can Help

UniqueSide sets up CI/CD pipelines for every product we deliver. Across 40+ shipped products, we have standardized on GitHub Actions for testing and Vercel or Docker-based deployments depending on the infrastructure requirements. Our 15-day MVP delivery at $8,000 includes a production-ready pipeline with automated testing, preview deployments, and environment management from day one.

We configure the pipeline early in development so every commit is validated automatically, reducing bugs and making deployments a non-event rather than a source of anxiety.

Learn more about our MVP development services.

Frequently Asked Questions

How long should a CI pipeline take to run?

Target under 5 minutes for the full pipeline. Slow pipelines kill developer productivity because engineers context-switch while waiting. Use dependency caching, parallel test execution, and incremental builds to keep times low. If your pipeline exceeds 10 minutes, audit each step for bottlenecks.

Should I run end-to-end tests in CI?

Yes, but selectively. Run your full unit and integration test suite on every PR. Run end-to-end tests (Playwright, Cypress) on critical user flows only, and consider running them only on merges to main or on a scheduled basis. E2E tests are slow and flaky, so limit them to high-value paths like authentication, checkout, and core workflows.

What is the difference between continuous delivery and continuous deployment?

Continuous delivery means every merge to main produces a release candidate that can be deployed with a single click. Continuous deployment means every merge to main automatically deploys to production without manual approval. Most teams start with continuous delivery and move to continuous deployment as their test coverage and monitoring improve.