Episode 10 – Production CI/CD for Frontend (GitHub Pages, React & Vite)
This is the final episode of the series.
So far, we’ve learned:
- what CI/CD is
- how GitHub Actions workflows work
- how to trigger, secure, reuse, debug, and optimize pipelines
Now it’s time to put everything together and design a real production-grade CI/CD pipeline for a frontend app.
This is how things are done in real teams.
The Goal of a Frontend CI/CD Pipeline
A good frontend pipeline should:
✅ Catch bugs before merge
✅ Be safe for pull requests
✅ Be fast for developers
✅ Deploy only trusted code
✅ Protect production
✅ Be easy to reason about
We’ll design a pipeline that does exactly that.
Step 1️⃣ Split CI and CD (Very Important)
CI and CD are different responsibilities.
🔵 CI (Continuous Integration)
- Runs on pull requests
- No secrets
- No deployments
- Validates code quality
🟢 CD (Continuous Deployment)
- Runs after merge
- Uses secrets
- Deploys to production
- Protected by environments
This separation is non-negotiable in production systems.
Step 2️⃣ CI Workflow (Pull Requests)
This workflow answers:
“Is this code safe to merge?”
name: Frontend CI
on:
pull_request:
branches: [main]
permissions:
contents: read
jobs:
ci:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 18
- run: npm ci
- run: npm run lint
- run: npm test
- run: npm run build
Why this is safe:
- No secrets
- Safe for forked PRs
- Fast feedback
- Fails early
Step 3️⃣ CD Workflow (Deploy to GitHub Pages)
This workflow answers:
“Deploy this code for users.”
GitHub now officially recommends GitHub Actions for Pages deployment.
Production Deployment Workflow
name: Deploy to GitHub Pages
on:
push:
branches: [main]
permissions:
contents: read
pages: write
id-token: write
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 18
- run: npm ci
- run: npm run build
- uses: actions/upload-pages-artifact@v3
with:
path: dist
deploy:
needs: build
runs-on: ubuntu-latest
environment: github-pages
steps:
- uses: actions/deploy-pages@v3
What this gives you:
- Clean build → deploy separation
- Official Pages deployment
- Secure permissions
- Environment tracking
Step 4️⃣ Why This Pipeline Is Production-Ready
Let’s connect this to everything we learned in the series:
| Concept | Where it’s used |
|---|---|
| CI vs CD | Separate workflows |
| Events |
pull_request vs push
|
| Runners | GitHub-hosted Ubuntu |
| Actions | checkout, setup-node, deploy |
| Secrets | Only in CD |
| Environments | GitHub Pages |
| Artifacts | Build output |
| Security | Least privilege |
| Debugging | Clear step names |
This is not a demo pipeline — this is real-world quality.
Step 5️⃣ Common Frontend CI/CD Mistakes (Avoid These 🚨)
❌ Deploying on every push
❌ Using secrets in CI
❌ Mixing CI and CD logic
❌ No environment protection
❌ Long inline scripts
❌ No caching strategy
If your pipeline feels “magical”, it’s probably fragile.
Final Mental Model (The Entire Series in One Diagram)
Pull Request
↓
CI (lint + test + build)
↓
Merge to main
↓
CD (build + deploy)
↓
Users 🚀
Everything in GitHub Actions supports this flow.
What You’ve Achieved 🎉
If you followed this series, you now understand:
✔️ GitHub Actions fundamentals
✔️ CI vs CD clearly
✔️ Security & permissions
✔️ Secrets & environments
✔️ Cache & artifacts
✔️ Reusable workflows
✔️ Debugging strategies
✔️ Production frontend deployment
This is senior-level CI/CD knowledge.
Final Words
Most developers use GitHub Actions by copying snippets.
Very few:
- understand why things work
- design pipelines intentionally
- think in terms of safety and scale
If you do, you’re already ahead.
Thanks for following this series 🙌
If it helped you, consider sharing it — it might help someone else too.
Happy shipping 🚀
— End of Series
Top comments (0)