CI/CD Pipeline with Vercel + GitHub: Automated Quality for Healthcare Apps

Shipping code to a healthcare application is not like shipping code to a blog. A bug in the booking flow could prevent patients from accessing care. A regression in the payment system could lose provider revenue. Our CI/CD pipeline with Vercel and GitHub ensures that every change passes automated quality gates before reaching production.

The Pipeline Architecture

Our CI/CD pipeline has four stages. First, local development where TypeScript checking and ESLint run on every file save. Second, push to GitHub which triggers GitHub Actions for automated testing and type checking. Third, Vercel preview deployment for visual verification and manual QA. Fourth, merge to main which triggers Vercel production deployment with automatic rollback capability.

Each stage catches different types of issues. Local development catches syntax and type errors immediately. GitHub Actions catches integration issues and test failures. Preview deployments catch visual regressions and UX problems. Production deployment monitoring catches performance regressions and runtime errors.

GitHub Actions Configuration

Our GitHub Actions workflow runs on every push to any branch and every pull request to main. The workflow installs dependencies, runs TypeScript type checking with tsc --noEmit, runs ESLint with zero-warning tolerance, and executes the Next.js build to catch any build-time errors.

The entire workflow completes in under 3 minutes. We cache node_modules and the Next.js build cache between runs, cutting repeated workflow times by 60%. The workflow uses the same Node.js version as our Vercel deployment to prevent "works on CI but not in production" issues.

Branch Protection

Our main branch has strict protection rules. Direct pushes are blocked — all changes must go through pull requests. Pull requests require the GitHub Actions workflow to pass before merging. This ensures that no code reaches production without passing type checking, linting, and build verification.

We do not require code review approval because I am a solo founder and there is no one to review. Instead, we rely on automated checks and preview deployment verification. The preview URL in the pull request lets me click through the affected pages and verify the change visually before merging.

Preview Deployments as QA

Vercel generates a unique preview URL for every pull request. This preview is a complete production-equivalent deployment with its own serverless functions, its own URL, and access to staging environment variables. I use this preview URL to verify changes on mobile and desktop, test edge cases, and confirm that the change looks correct in the context of the full application.

For healthcare features like booking flow changes or payment integrations, preview deployments are essential. I can test the entire end-to-end flow on the preview URL with test Stripe credentials before the code touches production. This eliminates the risk class of "deployed and then discovered it was broken."

Zero-Downtime Production Deployment

When a pull request is merged to main, Vercel starts the production deployment automatically. The build runs TypeScript checking, ESLint, and next build. If any step fails, the deployment is rejected and the previous production deployment continues serving traffic unchanged.

Successful deployments are atomically swapped at the edge. There is no downtime, no mixed-version state, and no cold start period. Vercel keeps the previous deployment available for instant rollback. If monitoring reveals an issue after deployment, I can revert to the previous version in under 10 seconds from the Vercel dashboard.

Environment Variable Safety

Our CI/CD pipeline enforces environment variable safety through several mechanisms. Preview deployments use staging environment variables — they never connect to production databases or production Stripe accounts. Sensitive environment variables are scoped to production only in the Vercel dashboard. GitHub Actions workflows do not have access to any production secrets.

This separation ensures that a compromised preview deployment or failed GitHub Action cannot expose production credentials. Even if an attacker gained access to our GitHub repository, they could not extract production Supabase or Stripe keys because those keys only exist in Vercel's production environment scope.

Monitoring After Deployment

Deployment is not the end of the pipeline — it is the beginning of monitoring. After every production deployment, we watch Vercel Analytics for performance regressions, check Supabase logs for database errors, and monitor Stripe webhooks for payment processing issues. Any anomaly triggers investigation.

Our alert thresholds are: LCP increase over 200ms, error rate above 0.1%, and booking completion rate drop below 95%. These thresholds have caught two regressions that automated testing missed — a CSS change that broke mobile layout and a middleware change that slowed authenticated page loads. Both were caught within minutes and rolled back before significant user impact.