Module 6 — CI/CD & Quality Gates

Learning Objectives

By the end of this module, you will be able to:

• Understand the role of Continuous Integration (CI) and Continuous Deployment (CD)
• Construct a GitHub Actions workflow to run test suites automatically
• Enforce pull request validation to prevent broken code from merging
• Interpret and mandate code coverage reports in the pipeline
• Design a zero-downtime deployment pipeline

Continuous Integration (CI)

Continuous Integration is the practice of merging all developer working copies to a shared mainline (like the main branch) several times a day.

To ensure that the main branch is always stable, we implement a CI Pipeline. Every time a developer opens a Pull Request (PR), an automated server boots up, downloads the code, and runs all the tests.

If the tests fail, the PR is blocked. This is known as a Quality Gate.

GitHub Actions

GitHub Actions is the most popular CI/CD platform for modern JavaScript projects. You configure it using YAML files placed in the .github/workflows/ directory.

A Basic Testing Pipeline

yaml
# .github/workflows/ci.yml
name: CI Pipeline

# Trigger the workflow on pushes to main and any Pull Request
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
    # 1. Checkout the code
    - uses: actions/checkout@v3

    # 2. Setup Node.js
    - name: Use Node.js 18.x
      uses: actions/setup-node@v3
      with:
        node-version: 18.x
        cache: 'npm'

    # 3. Install dependencies
    - run: npm ci

    # 4. Run Linter
    - run: npm run lint

    # 5. Run Unit & Integration Tests (Jest)
    - run: npm run test

    # 6. Run E2E Tests (Playwright)
    - run: npx playwright install --with-deps
    - run: npm run test:e2e

When a developer opens a PR, GitHub will execute these steps sequentially. If npm run test fails, GitHub will place a red "X" on the PR, preventing it from being merged.

Pull Request Validation & Coverage

Running tests is good, but enforcing test coverage ensures the team isn't writing code without writing tests.

You can configure Jest to fail the CI pipeline if coverage drops below a certain threshold.

javascript
// jest.config.js
module.exports = {
  coverageThreshold: {
    global: {
      branches: 80,
      functions: 80,
      lines: 80,
      statements: 80,
    },
  },
};

When running npm run test --coverage in your pipeline, Jest will return a non-zero exit code if coverage is 79%, automatically failing the GitHub Action and blocking the PR.

Continuous Deployment (CD)

Once code merges into main and passes all CI tests, Continuous Deployment takes over to automatically release the code to production.

If your tests are comprehensive (Unit + Integration + E2E), you can deploy with absolute confidence, achieving multiple deployments per day.

Deployment Pipelines

A standard modern pipeline looks like this:

1. Build: Compile TypeScript, bundle React (Webpack/Vite/Next.js).
2. Test: Run the CI pipeline (Jest, Playwright).
3. Staging: Deploy the build to an isolated staging environment (e.g., Vercel Preview Environments).
4. Smoke Test: Run a rapid subset of E2E tests against the staging URL.
5. Production Release: Swap the staging build into production seamlessly.

For platforms like Vercel or Netlify, this pipeline is largely managed for you out-of-the-box. For backend services on AWS/GCP, you might add steps to build Docker containers and push them to a registry.

Key Takeaways

• Tests only protect the codebase if they are enforced automatically via CI pipelines.
• GitHub Actions workflows define the steps to build, lint, and test code on every Pull Request.
• Quality gates block broken code or insufficient coverage from merging into main.
• A robust Continuous Deployment (CD) pipeline relies entirely on the trust established by the testing suite.

Knowledge Check

Question 1: A team of developers relies solely on running npm run test locally on their own machines before pushing code. Over time, the main branch frequently breaks because developers forget to run the tests, or they run them against outdated databases. What is the fundamental solution to this problem?

• A) Mandate that developers sign a checklist before merging their Pull Requests.
• B) Implement a Continuous Integration (CI) pipeline that automatically executes the test suite on a clean server for every Pull Request, blocking the merge if any tests fail.
• C) Switch from Jest to a faster test runner like Vitest so developers are more likely to run the tests locally.
• D) Implement Continuous Deployment (CD) to instantly push code to production, bypassing the main branch entirely.

Question 2: A GitHub Actions CI pipeline is configured to run npm run test --coverage. However, developers realize they can bypass writing tests entirely by pushing code with 0% coverage; the pipeline still passes because the few existing tests pass successfully. How do you configure Jest to automatically block Pull Requests that fail to meet a minimum testing standard?

• A) Set coverageThreshold in jest.config.js to define minimum percentages for branches, functions, and lines. If the coverage falls below this, Jest will exit with an error code and fail the CI job.
• B) Add a custom bash script in the GitHub Action that parses the HTML coverage report and searches for the string "0%".
• C) Require manual approval from a QA manager on all Pull Requests via GitHub's branch protection settings.
• D) Use the npm audit command in the pipeline to automatically write missing tests.

Question 3: What is the primary prerequisite for successfully adopting a robust Continuous Deployment (CD) pipeline where code merges directly to production multiple times a day?

• A) A staging environment configured identically to production.
• B) A monolithic architecture rather than microservices.
• C) Absolute trust in an automated, comprehensive testing suite (Unit, Integration, E2E) that guarantees regressions will be caught before deployment.
• D) A dedicated release management team to manually approve deployments on Fridays.

You have traversed the entire landscape of JavaScript testing. You understand the theory, the frameworks, and the automation. Now, it is time to put everything together in a single, comprehensive project.

Next: Module 7 — Capstone Project →