CI/CD & Reliability
Two questions decide whether a team ships with confidence. How does a change reach production safely and repeatably? — that is CI/CD. How does the running service stay reliable, and how do you know when it is not? — that is SRE. They are the same coin: a pipeline that deploys ten times a day is only an asset if each deploy can be rolled back in seconds and a bad one is caught before it burns the whole user base.
The delivery half is a mental discipline before it is a tool. You build the artifact once, tag it with a commit SHA, and promote that exact bytes through dev, staging, and prod — never rebuild per environment, never chase a mutable latest tag. You choose a rollout strategy — rolling, blue-green, or canary — to trade capacity for blast radius. And you decouple deploy (code on the box) from release (feature on for users) with feature flags.
The reliability half is about measuring the right thing and failing gracefully. You define an SLI, set an SLO, and spend the error budget it implies to gate how fast you ship. You watch the four golden signals. And you make failure survivable: retries with backoff, jitter and a budget, guarded by idempotency and circuit breakers, so one slow dependency degrades instead of cascades.
Topic map
- CI/CD pipelines — CI vs Continuous Delivery vs Continuous Deployment, fail-fast stages, build-once-promote-many, rolling/blue-green/canary, feature flags, pipeline secrets, and DORA metrics.
- Reliability & SRE — SLI/SLO/SLA, error budgets, the golden signals, toil, blameless postmortems, MTTR, retry storms, idempotency, circuit breakers, and graceful degradation.
Common traps
| Mistake | Consequence |
|---|---|
| Rebuilding the artifact per environment | You test one binary and ship a different one — "works in staging, breaks in prod" |
Deploying a mutable latest tag | The pod already ran latest, so nothing rolls out and there is no version to roll back to |
| Confusing blue-green with canary | You promise instant switch but describe gradual traffic, or size 2x capacity for a canary |
| Treating 100% availability as the target | You freeze all releases chasing an impossible number instead of spending an error budget |
| Retrying immediately with no backoff or jitter | A partial outage becomes a total one — the retry storm you caused |
| Retrying a non-idempotent call | A "safe" retry double-charges or double-writes |
Interview relevance
CI/CD and SRE are asked to see whether you think in systems and trade-offs or recite tool names. Saying "build once, tag by SHA, promote the same artifact, and gate the next stage on the golden signals" instantly reads as someone who has run production.
Typical checks:
- The exact line between CI, Continuous Delivery, and Continuous Deployment.
- Why
latestproduces no rollout, and what build-once-promote-many fixes. - Blue-green vs canary: instant switch and 2x capacity vs progressive, metric-gated traffic.
- How an error budget turns an SLO into a release-velocity decision.
- Why retries need backoff, jitter, a budget, and idempotency — and what a retry storm is.
Common wrong answer: "just add retries and it becomes reliable." Naive retries are the classic way to amplify an outage; reliability comes from backoff with jitter, a retry budget, circuit breakers, and degrading gracefully instead of hammering a wounded dependency.