Release path
Where does each kind of bad change get caught, and who sees it?
Run a service, GitOps or model release through its gates. Inject a fault, choose a rollout strategy, and see how far it travels and how many users it reaches.
First step sends 5% of traffic. Rollback is shifting that weight back.
- Lint + unitWaiting
Fast feedback, before any image exists.
- Build imageWaiting
Multi-stage Docker build, tagged with the commit SHA.
- ScanWaiting
Dependency and image scanning. Fixable criticals block the merge.
- StagingWaiting
Deploys the exact image digest that production will get.
- IntegrationWaiting
Tests the real dependencies and contracts.
- ProductionWaiting
Progressive rollout using the chosen strategy.
- Verify SLOWaiting
Compares error rate and latency with the previous release.
Choose a fault and run the release.
One pipeline, three dialects
The service pipeline above as illustrative configuration: the stages carry over, and only the syntax changes. Trimmed for reading, so treat these as sketches and not as drop-in files.
jobs:
build:
runs-on: ubuntu-latest
permissions: { id-token: write, contents: read }
steps:
- uses: actions/checkout@v4
- run: make test
- run: docker build -t $IMAGE:$GITHUB_SHA .
- uses: aquasecurity/trivy-action@0.28.0
with:
image-ref: ${{ env.IMAGE }}:${{ github.sha }}
severity: CRITICAL
ignore-unfixed: true
exit-code: 1
deploy:
needs: build
environment: production # required reviewers live here
steps:
- run: helm upgrade app ./chart --set image.tag=$GITHUB_SHA --atomicHow the model works
The earliest active fault fails its stage, and later stages are skipped. Faults that only appear under production traffic roll back and report exposure for the chosen strategy.
What it leaves out
- Exposure uses fixed assumptions: a 5% canary step, a 25% rolling batch, and a full blue-green cutover.
- It does not model how long a fault runs before detection, which also determines the real impact.
Covers
- CI/CD
- GitOps
- MLOps
- Jenkins, GitHub Actions and GitLab
- Progressive delivery