Build Validation Strategy
Overview
We use multiple layers of validation to ensure code quality before deploying to Vercel:
- Local Git Hooks - Immediate feedback on commit
- Docker Testing - Consistent environment testing
- GitHub Actions CI - Automated validation on push/PR
- Vercel Preview Deployments - Final validation
Local Development
Quick Validation
# Run type checking and tests
pnpm run validate
# Or use Make
make validate
Docker Testing
# Test build in Docker (same as Vercel environment)
make docker-test
# Run full production build locally
make docker-prod
# Visit http://localhost:8080
Pre-Deployment Checklist
Before pushing to main:
# Run complete validation suite
make pre-deploy
This runs:
- TypeScript type checking
- All tests
- Docker build test
- Production build verification
Git Hooks
Husky automatically runs validation on commit:
- TypeScript build check
- Test suite execution
To skip hooks in emergency:
git commit --no-verify -m "Emergency fix"
CI/CD Pipeline
GitHub Actions runs on every push:
- Validate Job: Linting, type checking, tests
- Docker Build: Tests both dev and production builds
- Deploy Check: Simulates Vercel build
Docker Commands
# Development with hot reload
docker-compose up dev
# Run tests in container
docker-compose run --rm test
# Production preview
docker-compose up prod
# Clean rebuild
docker-compose build --no-cache
Troubleshooting
Build fails locally but not in Docker
# Clean and reinstall
rm -rf node_modules pnpm-lock.yaml
pnpm install
Docker build is slow
# Use BuildKit for better caching
DOCKER_BUILDKIT=1 docker build .
Type errors not caught
# Run strict type check
pnpm run typecheck
Best Practices
- Always run
make validatebefore pushing - Use Docker for production-like testing
- Don't skip CI checks
- Fix warnings, not just errors
- Keep dependencies up to date
Environment Variables
For Docker testing with real services:
# Create .env.docker
cp .env .env.docker
# Edit as needed
# Run with env file
docker-compose --env-file .env.docker up test