End-to-End CI/CD Pipeline Project
Part of the DevOps Roadmap
In short
This is the project interviewers open first. One repo where every push is built, tested, scanned and deployed on its own shows you can do the core of DevOps, not just talk about it.
The flagship portfolio piece — build on Phase 6's practice project with a more polished, well-documented pipeline covering build, test, and deployment for a real application.
Think of it like this
The juice bottling line
In a bottling plant, empty bottles go in one end and sealed crates come out the other. Wash, fill, cap, check, pack, with no one carrying bottles by hand. If a cap is loose, that bottle is pulled off the line. Your pipeline is that line for code.
Watch it happen
The pipeline you'll build
1/6A push or pull request to main starts the workflow. Pull requests run tests only; main goes all the way.
The big ideas
What you need to know
Must-have: real app
Use a small but real app with a database or API, not hello world. It gives your tests and deploys something to prove.
Build once, deploy many
Tag the image with the commit SHA and promote that same image from staging to production.
Secrets done properly
Registry and cloud credentials live in the CI's secret store or come from OIDC, never in the YAML file.
A README that explains
Add a diagram of the stages, how to run it, and why you made each choice. Reviewers read this first.
See it in code
Walk through the code
1# .github/workflows/deploy.yml (the key jobs)2jobs:3 build:4 runs-on: ubuntu-latest5 steps:6 - uses: actions/checkout@v47 - run: npm ci && npm test8 - run: docker build -t ghcr.io/${{ github.repository }}:${{ github.sha }} .9 - run: trivy image --severity CRITICAL --exit-code 1 ghcr.io/${{ github.repository }}:${{ github.sha }}10 deploy-prod:11 needs: [build, deploy-staging]12 environment: production13 runs-on: ubuntu-latest14 steps:15 - run: ./deploy.sh ghcr.io/${{ github.repository }}:${{ github.sha }}1/4A clean runner checks out the code and runs the tests. If npm test fails, nothing below runs.
Trimmed to the tricky parts: docker login, the push step and the staging job are left out. environment: production is where GitHub can require a reviewer's approval.
Save yourself the pain
Common mistakes
Oops
Rebuilding the image separately for production.
Do this instead
Promote the image staging already tested. A rebuild can pull a different base image or dependency and ship untested code.
Oops
A pipeline that only works because of a setting you changed by hand once.
Do this instead
Keep everything in the repo: workflow files, deploy script, infra code. Someone else should be able to fork it and run it.
Your mission
Milestone 1: green on every push
Quick check
Why tag images with the commit SHA instead of 'latest'?
Go deeper
- 1Extend your Phase 6 project with additional stages (security scanning, multiple environments).
- 2Deploy to a real (even free-tier) environment, not just simulate the deployment step.
- 3Write a README explaining every stage and the reasoning behind your pipeline design.
More projects at this stop
Kubernetes Cluster Deployment Project
Infrastructure as Code Project (Terraform)
Monitoring Stack Setup (Prometheus + Grafana)
Automated Deployment With Rollback Project
Multi-Environment (Dev / Staging / Prod) Setup
Portfolio Website or GitHub Showcase
Stuck on this topic? Ask an Insider
Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.
