Make a deployment boring

Why "boring" is the goal

An exciting deployment is a risky one. “Works on my machine” means the environment isn't reproducible; a stressful release means there's no safety net. The goal: to deploy on a Friday at 5pm without thinking about it.

Infrastructure as code

Infra clicked by hand in the console isn’t reproducible and nobody knows what changed. In Terraform, infra becomes code: versioned, reviewed in a pull request, recreatable identically.

# infrastructure.tf — l'infra est du code, versionne et relisible
resource "aws_instance" "web" {
  ami           = "ami-0abc"
  instance_type = "t3.large"
  tags = { Project = "shop", Env = "prod" }
}
# "terraform apply" recree la meme infra a l'identique, partout

The pipeline

The key principle: the same deploy script runs in CI and locally. No secret logic hidden in the GitHub UI — if CI is down, you run the script by hand and get the same result.

# .github/workflows/deploy.yml — chaque merge sur main deploie
name: deploy
on:
  push: { branches: [main] }
jobs:
  ship:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build && npm test
      - name: deploy
        run: ./scripts/deploy.sh   # meme script que tu peux lancer en local

The net: health checks + rollback

The new version only takes traffic after proving it’s alive. The load balancer polls a /health endpoint; until it returns 200, the old version stays in place.

// l'app expose un endpoint que le load balancer interroge
app.get("/health", (_, res) => res.json({ ok: true }));
// le deploiement attend que /health reponde 200 avant de basculer
// sinon : rollback automatique, l'ancienne version reste en place

Blue-green or canary: picking your net

I mentioned blue-green above; in practice I pick between two strategies depending on risk. With blue-green, two identical environments run in parallel: I switch 100% of traffic from "blue" to "green" at once, and rollback is just a traffic switch back to the still-running "blue." With canary, I shift traffic in steps — 5%, then 25%, then 100% — and only advance if error rates and latency stay healthy.

Readiness vs liveness, and measuring the boredom

One /health isn't enough: separate "alive" from "ready"

The /health I showed above actually hides two different questions, and Kubernetes splits them explicitly with its liveness, readiness and startup probes. Readiness says "I can take traffic now" (DB connected, cache warm): if it fails, I'm pulled from the load balancer without being killed. Liveness says "I'm alive, don't restart me": if it fails, the container is restarted. Conflating the two leads to restart loops the moment a dependency slows down.

// deux endpoints distincts, deux responsabilites
// /livez  : le process tourne-t-il ? (ne teste PAS les dependances)
app.get("/livez", (_req, res) => res.status(200).send("ok"));
// /readyz : puis-je servir du trafic ? (teste les dependances)
app.get("/readyz", async (_req, res) => {
  try {
    await db.query("SELECT 1");        // la base repond ?
    await redis.ping();                // le cache repond ?
    res.status(200).send("ready");
  } catch {
    res.status(503).send("not ready"); // retire du LB, pas de restart
  }
});

Measuring that it's actually boring: DORA metrics

"Boring" isn't just a feeling — it's measurable. The DORA metrics, from six years of Google research, capture both the velocity and the stability of a delivery pipeline. The report's key counterintuition: speed and stability aren't a trade-off — the best teams deploy more often AND recover faster.

Sources & further reading