Scaling and CI-CD

Back

Loading concept...

🚀 Scaling Playwright Tests: From Slow to Lightning Fast!

The Big Picture: Running Tests Like a Well-Organized Team

Imagine you’re the coach of a cleaning crew. You have 100 rooms to clean in a big hotel. Would you send one person to clean all 100 rooms one by one? That would take forever!

Instead, you’d split your team into groups. Each group cleans different floors at the same time. That’s sharding — splitting work so everyone works together and finishes faster!


🧩 What is Sharding?

Sharding means breaking your tests into smaller pieces called “shards.”

Think of a pizza. If you have 8 slices and 4 hungry friends, each friend gets 2 slices. They all eat at the same time, so dinner is done fast!

Your Tests = 🍕 Pizza
Shards = 🍕 Slices
Machines = 👨‍👩‍👧‍👦 Friends eating

Real Example:

If you have 100 tests and 4 machines:

  • Machine 1 runs tests 1-25
  • Machine 2 runs tests 26-50
  • Machine 3 runs tests 51-75
  • Machine 4 runs tests 76-100

All run at the same time = 4x faster!


⚙️ Shard Configuration

Setting up sharding is like telling your cleaning crew which floor to clean.

The Magic Command:

npx playwright test --shard=1/4

This means: “I am shard 1 out of 4 total shards.”

Breaking It Down:

--shard=CURRENT/TOTAL

CURRENT = Which piece am I?
TOTAL = How many pieces total?

Example Commands for 4 Machines:

# Machine 1 runs:
npx playwright test --shard=1/4

# Machine 2 runs:
npx playwright test --shard=2/4

# Machine 3 runs:
npx playwright test --shard=3/4

# Machine 4 runs:
npx playwright test --shard=4/4

Each machine automatically gets its fair share of tests!


📊 Merging Shard Reports

Here’s a problem: each shard creates its own report. But you want ONE report showing everything!

It’s like having 4 kids write parts of a story. You need to combine their pages into one book!

Step 1: Save Reports as Blobs

Tell Playwright to save special “blob” reports:

npx playwright test --shard=1/4 \
  --reporter=blob

Each shard saves its results in a blob file.

Step 2: Merge All Blobs

After all shards finish, combine them:

npx playwright merge-reports \
  --reporter=html ./blob-reports

Now you have ONE beautiful HTML report!

graph TD A["Shard 1 Report"] --> E["Merge Tool"] B["Shard 2 Report"] --> E C["Shard 3 Report"] --> E D["Shard 4 Report"] --> E E --> F["One Combined Report"]

🔄 CI/CD Integration

CI/CD stands for Continuous Integration / Continuous Deployment.

Think of it like an automatic robot butler. Every time you make changes to your code, the robot automatically:

  1. ✅ Grabs your new code
  2. ✅ Runs all your tests
  3. ✅ Tells you if anything broke
  4. ✅ Deploys if everything passes

You don’t have to remember to test — the robot does it for you!

Why CI/CD + Playwright = Amazing

Without CI/CD With CI/CD
You forget to run tests Tests run automatically
Bugs hide for weeks Bugs found in minutes
Manual, boring work Automatic, reliable

🐙 GitHub Actions Setup

GitHub Actions is GitHub’s built-in robot butler. Let’s teach it to run Playwright!

Create Your Workflow File:

File: .github/workflows/playwright.yml

name: Playwright Tests
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm ci

      - name: Install Playwright
        run: npx playwright install --with-deps

      - name: Run tests
        run: npx playwright test

      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/

What Each Part Does:

graph TD A["Code Pushed"] --> B["GitHub Sees Change"] B --> C["Starts Ubuntu Machine"] C --> D["Downloads Your Code"] D --> E["Installs Node.js"] E --> F["Installs Dependencies"] F --> G["Runs Playwright Tests"] G --> H["Saves Report"]

Sharded GitHub Actions (Super Fast!):

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm ci

      - name: Install Playwright
        run: npx playwright install --with-deps

      - name: Run tests
        run: |
          npx playwright test --shard=${{ matrix.shard }}/4

The matrix creates 4 parallel jobs automatically!


🐳 Running in Docker

Docker is like a shipping container for your code. Everything your tests need is packed inside, so they run the same everywhere.

Imagine a lunchbox. No matter where you take it — school, park, office — your lunch is always the same inside!

Why Docker?

Problem Docker Solution
“Works on my computer!” Works everywhere the same
Installing browsers is hard Browsers pre-installed
Different versions cause bugs Exact same environment

Official Playwright Docker Image:

docker pull mcr.microsoft.com/playwright:v1.40.0-jammy

This image comes with:

  • ✅ Node.js
  • ✅ Chromium, Firefox, WebKit
  • ✅ All dependencies

Running Tests in Docker:

docker run -it --rm \
  -v $(pwd):/work \
  -w /work \
  mcr.microsoft.com/playwright:v1.40.0-jammy \
  npx playwright test

What This Command Does:

docker run         → Start a container
-it                → Interactive mode
--rm               → Delete container after done
-v $(pwd):/work    → Share your code folder
-w /work           → Work in that folder
mcr.microsoft...   → Use Playwright image
npx playwright test → Run tests!

Dockerfile for Your Project:

FROM mcr.microsoft.com/playwright:v1.40.0-jammy

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .

CMD ["npx", "playwright", "test"]

GitHub Actions + Docker:

jobs:
  test:
    runs-on: ubuntu-latest
    container:
      image: mcr.microsoft.com/playwright:v1.40.0-jammy
    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npx playwright test

🎯 Putting It All Together

Here’s the complete picture of a professional test setup:

graph TD A["You Push Code"] --> B["GitHub Actions Triggered"] B --> C["4 Docker Containers Start"] C --> D["Shard 1/4"] C --> E["Shard 2/4"] C --> F["Shard 3/4"] C --> G["Shard 4/4"] D --> H["Blob Report 1"] E --> I["Blob Report 2"] F --> J["Blob Report 3"] G --> K["Blob Report 4"] H --> L["Merge Reports"] I --> L J --> L K --> L L --> M["Final HTML Report"] M --> N["Deploy if All Pass"]

🌟 Quick Summary

Concept What It Does Analogy
Sharding Splits tests across machines Pizza slices for friends
Shard Config Tells each machine its portion Assigning floors to cleaners
Merge Reports Combines results into one Making one book from chapters
CI/CD Automatic testing on code changes Robot butler
GitHub Actions GitHub’s CI/CD tool The robot’s brain
Docker Same environment everywhere Lunchbox for code

🚀 You’re Ready!

Now you know how to:

  1. ✅ Split tests with sharding
  2. ✅ Configure shards with --shard=X/Y
  3. ✅ Merge reports into one beautiful file
  4. ✅ Set up automatic testing with CI/CD
  5. ✅ Create GitHub Actions workflows
  6. ✅ Run tests in Docker containers

Your tests will run faster, more reliably, and automatically. That’s the power of scaling!

Remember: Start small. Get one shard working, then add more. Build your CI/CD step by step. Before you know it, you’ll have a professional test pipeline!

Loading story...

Story - Premium Content

Please sign in to view this story and start learning.

Upgrade to Premium to unlock full access to all stories.

Stay Tuned!

Story is coming soon.

Story Preview

Story - Premium Content

Please sign in to view this concept and start learning.

Upgrade to Premium to unlock full access to all content.