Rendre un déploiement ennuyeux

Pourquoi « ennuyeux » est un objectif

Un déploiement excitant, c'est un déploiement risqué. « Ça marche chez moi » veut dire que l'environnement n'est pas reproductible ; une mise en prod stressante veut dire qu'il n'y a pas de filet. L'objectif : pouvoir déployer un vendredi à 17h sans y penser.

Infra as code

Une infra cliquée à la main dans la console n'est pas reproductible et personne ne sait ce qui a changé. En Terraform, l'infra devient du code : versionné, relu en pull request, recréable à l'identique.

# 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

Le pipeline

Le principe clé : le même script de déploiement tourne en CI et en local. Pas de logique secrète cachée dans l'interface GitHub — si la CI tombe, tu lances le script à la main et tu obtiens le même résultat.

# .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

Le filet : health checks + rollback

La nouvelle version ne prend le trafic qu'après avoir prouvé qu'elle est vivante. Le load balancer interroge un endpoint /health ; tant qu'il ne répond pas 200, l'ancienne version reste en 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 ou canary : choisir son filet

J'ai évoqué le blue-green plus haut ; en pratique je choisis entre deux stratégies selon le risque. En blue-green, deux environnements identiques tournent en parallèle : je bascule 100% du trafic de « blue » vers « green » d'un coup, et le rollback est un simple retour de trafic vers « blue » resté debout. En canary, je décale le trafic par paliers — 5%, puis 25%, puis 100% — et je n'avance que si les erreurs et la latence restent saines.

Readiness vs liveness, et mesurer l'ennui

Un /health ne suffit pas : distingue « vivant » et « prêt »

Le /health que j'ai montré plus haut cache en réalité deux questions différentes, et Kubernetes les sépare explicitement avec ses probes liveness, readiness et startup. La readiness dit « je peux recevoir du trafic maintenant » (DB connectée, cache chaud) : si elle échoue, on me retire du load balancer sans me tuer. La liveness dit « je suis vivant, ne me redémarre pas » : si elle échoue, on redémarre le conteneur. Confondre les deux mène à des redémarrages en boucle dès qu'une dépendance ralentit.

// 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
  }
});

Mesurer que c'est vraiment ennuyeux : les métriques DORA

« Ennuyeux » n'est pas qu'un ressenti, ça se mesure. Les métriques DORA — issues de six ans de recherche Google — capturent à la fois la vélocité et la stabilité d'une chaîne de livraison. La contre-intuition clé du rapport : vitesse et stabilité ne sont pas un compromis, les meilleures équipes déploient plus souvent ET récupèrent plus vite.

Sources & ressources