Project Brief — Complete CI/CD Pipeline for an E-Commerce App

You've spent five chapters learning the individual pieces: GitHub Actions workflows, Jenkins pipelines, matrix builds, sharding, caching, quality gates, coverage reporting, and notification routing. This capstone brings all of those pieces together into a single, coherent system — the kind of CI/CD pipeline a QA Lead would design and own at a real company.

The scenario

You're the QA Lead at ShopFast, a growing e-commerce startup. The engineering team has 10 developers, a QA team of three, and a product team that ships feature updates multiple times per week. The codebase has two components:

Backend: a Java Spring Boot API. Tests use Selenium WebDriver for UI smoke tests and Rest Assured for API tests. Build tool: Maven. Test framework: TestNG. Coverage: JaCoCo.

Frontend: a React/TypeScript application. Tests use Playwright for E2E tests. Package manager: npm. Coverage: Istanbul (via Vitest).

The team currently has no CI/CD. Everything is tested manually before a weekly release, which takes three days of QA effort and still ships bugs. Your job is to design and implement a pipeline that:

• Catches most bugs before they reach the QA team's manual testing queue
• Gives developers feedback within 5 minutes on every PR
• Runs comprehensive regression overnight, not during the workday
• Deploys to staging automatically after every merge to main
• Never allows main branch to break without immediate notification
• Gives the whole team visibility into test health without requiring them to watch dashboards

Your deliverables

This capstone has nine deliverables. You'll build them across the next three lessons. Here is the complete list so you can see how everything connects:

1. Three GitHub Actions workflow files:

• pr-checks.yml — runs on every PR: smoke tests, lint, type check. Target: under 5 minutes.
• nightly-regression.yml — runs at 2 AM: full backend + frontend test suite with sharding. Target: under 15 minutes with sharding.
• deploy-staging.yml — runs on merge to main: deploys backend and frontend to staging, runs post-deploy smoke tests.

2. Branch protection configuration: Which status checks are required before merging to main. Which teams can override. Whether up-to-date enforcement is on.

3. Caching strategy: Maven ~/.m2, npm node_modules, Playwright ~/.cache/ms-playwright. Every workflow uses cache; cold start is measured and documented.

4. Parallel execution plan: PR workflow: backend smoke (4 Maven threads) + frontend smoke (Playwright workers: 2) run as parallel jobs. Nightly: 4 shards for backend E2E, 3 shards for frontend E2E.

5. Quality gates:

• Tests: pass rate ≥ 95% (Maven retries: 1)
• Backend coverage: JaCoCo line coverage ≥ 80%
• Frontend coverage: Istanbul line coverage ≥ 75%
• SonarQube: no new critical issues on main

6. Test reporting:

• JUnit XML: parsed by dorny/test-reporter on PRs
• Allure: deployed to GitHub Pages for nightly runs, with 30-build history
• Coverage: Codecov for PR diff comments

7. Notification strategy:

• #qa-builds Slack: nightly failure/recovery notifications
• #releases Slack: staging deploy success/failure
• GitHub status checks: PR-level results (primary)
• README badges: PR checks, nightly, coverage

8. Post-deploy verification: After staging deploy, run a 5-test smoke suite against the live staging URL. Fail the deploy workflow if any post-deploy smoke tests fail.

9. Pipeline documentation: A docs/pipeline.md file explaining the pipeline for new team members: what runs when, how to add a new test, what to do when a gate fails, who owns what.

Assessing what you're starting with

Before building, audit the starting state:

Backend (Java): does mvn test run cleanly? How long does it take? Does it produce JUnit XML in target/surefire-reports/? Are tests tagged with TestNG groups (smoke, regression, api)?

Frontend (TypeScript/Playwright): does npm test run cleanly? Does npx playwright test work? Are tests tagged with @smoke? What's the baseline run time for the full suite?

No CI baseline: this is a greenfield pipeline. Every minute saved compared to manual testing is value delivered. The current manual QA cycle takes 3 person-days per release. After this pipeline, the expectation is: zero manual regression for most releases, with manual exploratory testing for new features only.

Architecture overview

The three workflows are independent but connected through the branch protection ruleset:

• PRs cannot merge until pr-checks / backend-smoke and pr-checks / frontend-smoke are green
• Every merge to main triggers deploy-staging, which includes a post-deploy smoke gate
• Nightly runs independently of PRs — its results feed into the Allure history and the #qa-builds Slack channel

The quality gates are cumulative: a PR must pass test gates, coverage gates, and (optionally) the SonarQube gate before the merge button is active. Each gate is a separate workflow job, so failures are specific — "coverage gate failed" is more actionable than "pipeline failed."

Before you start building

Work through these questions before writing a single line of YAML. The answers inform every decision in the next two lessons:

1. What is the fastest test you can run that gives meaningful confidence? This defines your smoke set. If the answer is "we don't have tagged smoke tests," your first task is tagging 10 tests before writing any pipeline YAML.

2. What does your staging environment need to be live? A database seed script? Specific environment variables? A running service? The deploy workflow needs to know.

3. Who gets Slack alerts, and for what events? Write down the channel names and the events. This prevents the "everything goes to #general" anti-pattern.

4. What counts as passing in your current manual QA cycle? If the team currently ships with 3 known bugs per release, a CI gate that requires 95% pass rate will immediately fail. Baseline the current state before setting thresholds.

5. How long is "acceptable" for the PR pipeline? The target is under 5 minutes. If your full backend test suite currently takes 20 minutes, the answer isn't to run all 20 minutes on every PR — it's to identify the smoke subset that runs in 3 minutes.

Write your answers down. The next lesson uses them as inputs to the actual workflow YAML.

⚠️ Common mistakes (planning phase)

• Designing the ideal pipeline instead of the current-state pipeline. If your tests aren't tagged today, a pipeline design that assumes @smoke tags doesn't help. Design for the state of your tests today; plan for improvements as a roadmap.
• Setting coverage thresholds higher than current coverage. If current coverage is 62%, setting an 80% gate blocks every PR until coverage improves. Set the gate at current coverage (62%) first, ship the pipeline, then raise the threshold 5% per quarter as the team improves.
• Building all three workflows at once. Scope to pr-checks.yml first. Get it green on a PR. Then add nightly. Then add deploy. Sequential delivery of value beats a perfect architecture that takes three weeks to finish.

🎯 Exercise

Before proceeding to the walkthrough: write your pipeline design on paper or in a text file. Include:

• The test command(s) for your smoke set (exact shell commands)
• The expected duration of each parallel job in pr-checks.yml
• The number of shards you'll use for nightly regression
• The Slack channel names and the events that trigger each
• The quality gate thresholds you'll start with

Compare your design to the walkthrough in the next lesson. Where they differ, think about why — sometimes your context justifies a different choice.