Testing & CI/CD — MVP Action Plan

1. Overview / TL;DR

The full standard (Software Testing & CI/CD Standard) answers "what should the end state look like?". This page answers the question you actually have first: "what do I do on Monday?" It is the MVP — the smallest amount of work that stops broken code from landing and regressions from shipping, applied one project at a time.

The whole plan fits in two weeks. If a project doesn't have the 3 things after Phase 2, it's not done — everything else is optional and can wait.

2. What "MVP" Means

The MVP is not "a little bit of testing". It is a definition of protected — three checks that take five minutes to verify on any repo. When all three pass, broken code cannot reach production unnoticed. That is the entire goal.

3. Phase 0 · Inventory (Half a Day)

You can't prioritize what you haven't listed. Copy this table, fill it in for every project (including internal tools and scripts — they're the cheapest to protect and the first to be forgotten), and score each row. Build nothing in this phase.

"Risk" is about blast radius: does it move money, hold user data, or serve paying users? "Activity" is about how often code changes — a dormant repo is already protected; an active one is bleeding.

4. Phase 1 · Pilot — The 3 Steps (1–2 Days)

Pick the pilot from the inventory score (see the ranking rule in Phase 0). Then do exactly three things — in this order, no skipping:

5. Phase 2 · Rollout (~1 Week)

Work through the inventory in score order, one project per day. For each project, repeat the same 3 steps, adapting only the tooling via the per-stack cheat table (section 7). The pipeline shape stays identical: lint → typecheck → tests → build on every PR.

6. Phase 3 · Level Up (Ongoing)

Once every project passes the 3 checks, the MVP has done its job. Everything after this point comes from the full standard — add items one at a time, each on its own, only when the previous one is actually working. Suggested order:

7. Already There? Skip-Ahead Fork (GitLab)

If your project already runs unit tests + SAST + dependency scanning in GitLab CI, you are past the MVP baseline — do not start at Phase 0. Your "three checks" are mostly in place; the next moves are about making what you already run enforce quality instead of just reporting it.

Step 1 in practice — GitLab: publish a Cobertura report from the test job (this also turns on the coverage-delta widget on every MR), then add a check job that fails below your threshold:

test:
  stage: test
  script:
    - npm test -- --coverage
  coverage: '/All files[^|]*\|[^|]*\s+([\d.]+)%/'
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

coverage-check:
  stage: test
  needs: [test]
  script:
    - |
      cov=$(grep -oP 'All files[^|]*\|\s*\K[\d.]+' coverage/coverage-summary.txt)
      if (( $(echo "$cov < 80" | bc -l) )); then
        echo "Coverage ${cov}% < 80% — failing the MR"; exit 1
      fi
      echo "Coverage ${cov}% ≥ 80% — gate passed"

Past the fork — operate the loop. If steps 1–6 are all green, you have finished the build phase of CI/CD: every "should we have this?" question is answered. The next phase is operate — verify deploys, keep the gates trustworthy, measure outcomes, and ratchet thresholds up quarterly instead of adding new ones.

8. Per-Stack Cheat Table

The MVP is technology-agnostic: same 3 checks, different tools. Use the stack's default runner — if the project already has one, keep it. This table is only for projects starting from zero.

9. CI Snippets — GitHub Actions & GitLab CI

Minimal, copy-paste, no extras. Both run the same 4 commands on every pull request: lint → typecheck → tests → build. Adapt the commands per stack from section 8.

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  verify:
    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 typecheck
      - run: npm test
      - run: npm run build

stages: [verify, build]

verify:
  stage: verify
  image: node:20
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  script:
    - npm ci
    - npm run lint
    - npm run typecheck
    - npm test

build:
  stage: build
  image: node:20
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  script:
    - npm ci
    - npm run build

10. Protected Checklist & 2-Week Calendar

Per-project protected checklist — tick all three, or the project is not done:

2-week calendar template — fill in project names from your inventory score:

11. One-Page Cheat Sheet

12. References

• 1
  Software Testing & CI/CD Standard — Deep Study

  The full reference this plan is the companion to: categories T1–T6, levels & pyramid, P0/P1/P2, quality gates, pipeline design, environments, governance.
• 2
  Testing & CI/CD Pipeline Architecture (diagram)

  Visual reference of the end-state pipeline this MVP grows into: 11 stages, 4 quality gates, PR / staging / production contexts.
• 3
  Martin Fowler — The Practical Test Pyramid

  Why the pyramid shape (many unit tests, few E2E) is the right default and what each level is for.
• 4
  Martin Fowler — Continuous Integration

  The original case for integrating and verifying every change — the backbone of Check 2.
• 5
  GitHub Actions Documentation

  Official docs for the GitHub Actions snippet in section 9 (workflows, status checks, branch protection).
• 6
  GitLab CI/CD Documentation

  Official docs for the GitLab snippet in section 9 (pipelines, rules, protected branches).
• 7
  Google Testing Blog — Just Say No to More End-to-End Tests

  The argument for keeping E2E minimal — why it's Phase 3, not part of the MVP.
• 8
  OWASP Top Ten

  The security risk catalog behind T3 — the starting point for the security level-up item.