← back to all projects
Deploy Pipeline for an Existing Project
Part 11 — CI/CD
Why This Project
CI/CD isn't a separate app — it's something you add to a real project. Take the
Freelancer Client Portal (or Splitwise Lite) and add a full deployment pipeline.
This teaches you that CI/CD is a skill you apply retroactively to existing codebases,
which is exactly how it works in the real world.
What to Build
A GitHub Actions workflow that lints, tests, and deploys your full stack app
automatically on every push to main. The pipeline should catch the same errors
you'd catch locally — broken tests, lint violations, type errors — and only
deploy if everything passes.
Requirements
- GitHub Actions workflow file (
.github/workflows/pipeline.yml)
- Steps: checkout → install deps → lint (ESLint) → run tests → build → deploy
- Lint step fails the pipeline if there are errors
- Test step runs your integration tests (needs a test database — use a MongoDB service container or Atlas test cluster)
- Deploy to Fly.io or Render on push to main (only if all previous steps pass)
- Environment secrets stored in GitHub Secrets: MongoDB URI, JWT secret, API keys
- Separate jobs for frontend and backend if they live in different directories
- Add a pipeline status badge to your README
- Create a PR, see the pipeline run on the PR, then merge
- Bonus: branch protection rules requiring the pipeline to pass before merging
Skills Practiced
GitHub Actions
CI/CD
YAML
automated testing
automated deployment
environment secrets
service containers
Pain Point to Notice
Your first pipeline will fail multiple times. Debugging CI is harder than local
debugging — you can't add a console.log and refresh. You push, wait for the runner,
read the logs, fix, push again. This slow feedback loop is frustrating but it teaches
you to think about your environment: what's installed, what env vars are set, what
services are running. "Works on my machine" stops being an excuse when CI disagrees.