CI/CD Pipelines for Modern Web and Mobile Teams

Building fast, reliable deployment pipelines with GitHub Actions, automated testing, and progressive delivery strategies.

A high-quality CI/CD pipeline is the nervous system of a productive engineering team. It transforms code changes from ideas into production reality with confidence, speed, and minimal manual intervention. Teams that invest in pipeline quality ship more often, catch bugs earlier, and spend less time fighting deployment fires. ## Pipeline Design Principles **Fast feedback**: The most important property of a CI pipeline is how quickly it reports failures. Pipelines that take 30+ minutes to run are ignored—developers push and work on other things while waiting. Optimize relentlessly for sub-10-minute pipelines for typical changes. **Fail fast**: Order pipeline stages so the fastest, most likely failures run first. Linting and type checking (seconds) should run before unit tests (minutes), which run before E2E tests (10+ minutes). **Parallelism**: Parallelize independent pipeline stages. Test suites should be sharded across multiple runners. Build and test jobs for different packages in a monorepo can run concurrently. **Reproducibility**: Pipeline runs should be deterministic. Pin dependency versions with lockfiles (`package-lock.json`, `yarn.lock`, `Cargo.lock`). Use Docker containers with pinned base images for build environments. ## GitHub Actions Pipeline Structure ```yaml name: CI/CD on: push: branches: [main] pull_request: branches: [main] jobs: lint-and-type-check: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '20' cache: 'npm' - run: npm ci - run: npm run lint - run: npm run type-check unit-tests: needs: lint-and-type-check runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: npm ci - run: npm test -- --coverage - uses: codecov/codecov-action@v4 e2e-tests: needs: unit-tests runs-on: ubuntu-latest strategy: matrix: shard: [1, 2, 3, 4] steps: - uses: actions/checkout@v4 - run: npm ci - run: npx playwright test --shard=$matrix.shard/4 deploy-preview: if: github.event_name == 'pull_request' needs: unit-tests runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: npm run build - run: npx vercel --token=$secrets.VERCEL_TOKEN deploy-production: if: github.ref == 'refs/heads/main' needs: [unit-tests, e2e-tests] runs-on: ubuntu-latest environment: production steps: - uses: actions/checkout@v4 - run: npm run build - run: npx vercel --prod --token=$secrets.VERCEL_TOKEN ``` ## Preview Environments Preview environments (deployment previews) are one of the highest-leverage pipeline investments. Every pull request gets a unique URL where reviewers can interact with the changes in a fully deployed environment. This catches visual regressions, UX issues, and integration problems that code review misses. Vercel, Netlify, and Render support preview deployments natively for web apps. For mobile, TestFlight (iOS) and Internal Testing (Android) provide equivalent distribution to QA and stakeholders. Tools like EAS Build (Expo) automate mobile preview builds from CI. ## Testing Strategy **Unit Tests (Jest, Vitest)**: Fast, isolated tests for business logic, utility functions, and individual component behavior. Should cover edge cases and error paths. Target 80%+ coverage on business-critical code, not 100% overall. **Integration Tests**: Test the interaction between components and services—component + data fetching, API endpoint + database. Use real dependencies where practical (test containers for PostgreSQL, MSW for API mocking in React tests). **End-to-End Tests (Playwright, Cypress)**: Test critical user flows from the browser's perspective. Maintain a small suite covering the happy path for your highest-value flows: signup, onboarding, checkout, core product action. Avoid E2E tests for every feature—they're expensive to write and maintain. **Visual Regression Tests (Chromatic, Percy)**: Screenshot components and pages on every PR and flag visual diffs for review. Essential for design system components. Integrate with Storybook for component-level visual testing. ## Progressive Delivery Progressive delivery decouples code deployment from feature activation: **Feature Flags**: Deploy code with features hidden behind flags. Gradually roll out features to percentages of users, targeting specific user segments or geographies. Roll back instantly by toggling the flag—no redeploy required. (LaunchDarkly, Statsig, Unleash) **Canary Deployments**: Route a small percentage of traffic (1-5%) to the new version. Monitor error rates and key metrics. Gradually increase traffic if metrics are healthy. Automated rollback if error rates spike above thresholds. **Blue/Green Deployments**: Maintain two identical production environments (blue and green). Deploy to the idle environment, run smoke tests, then switch traffic. Enables instant rollback by switching back. ## Mobile-Specific CI/CD Mobile CI/CD adds complexity: code signing, simulator/device testing, and multi-store distribution. **Code Signing Automation**: Use Fastlane Match to store certificates and provisioning profiles in an encrypted repository, ensuring consistent signing across team members and CI environments. **Automated Testing on Devices**: Use Maestro or Detox for mobile E2E testing. For device coverage, use cloud device farms (Firebase Test Lab, BrowserStack App Automate) to run tests across real device/OS combinations. **Release Automation**: Fastlane `deliver` (iOS) and `supply` (Android) automate submitting builds to app stores with metadata, screenshots, and release notes.