Un déploiement qui revient en arrière tout seul à 2h du matin

Avec personne qui surveille un déploiement en temps réel, c'est la différence entre un mauvais déploiement qui s'auto-répare en deux minutes et un mauvais déploiement qui reste tombé jusqu'à ce que je me réveille et le remarque.

Quatre étapes : prendre un instantané du tag d'image actuellement en fonctionnement, déployer le nouveau, le health-checker, et en cas d'échec redéployer automatiquement l'instantané et le health-checker aussi.

Instantané avant de toucher à quoi que ce soit. Sans enregistrer ce qui tourne actuellement, « revenir en arrière » n'a pas de cible définie.

current="$(docker inspect --format='{{index .Config.Image}}' app-backend)"
echo "$current" | sed -E 's#.*-backend:##' > "$LAST_GOOD_TAG_FILE"

Les migrations tournent comme un conteneur ponctuel, séparé du démarrage de la stack, pour qu'un échec de migration arrête le déploiement avant que du code incompatible avec le schéma ne tourne contre la base :

docker compose pull
docker compose run --rm --no-deps backend sh -c 'DATABASE_URL="$DIRECT_URL" npx prisma migrate deploy'
docker compose up -d

Health check avec une boucle de réessai bornée, pas une seule vérification. Une seule vérification juste après docker compose up -d échoue presque toujours — le conteneur a besoin de vrai temps pour démarrer et se connecter. La boucle lui laisse jusqu'à deux minutes avant de conclure qu'il est réellement cassé.

for i in $(seq 1 30); do
  body="$(docker compose exec -T backend curl -sS http://localhost:3002/health)"
  if echo "$body" | grep -q '"ok":true'; then exit 0; fi
  sleep 4
done

Le rollback ne se déclenche qu'en cas d'échec, et n'est pas non plus cru aveuglément — il passe par la même boucle de health check. Si même le rollback ne revient pas en bonne santé, le workflow sort en non-zéro et alerte pour une intervention manuelle. Pas d'auto-réessai infini qui pourrait masquer un état vraiment cassé.

Ce que ça n'attrape pas

Un health check qui passe signifie seulement que le back-end répond à /health — pas que le déploiement est correct. Un bug de logique subtil, une fonctionnalité cassée-mais-sans-crash, une fuite de mémoire lente passent tous droit à travers. Le rollback automatique attrape « cassé et tombé », pas « techniquement en marche mais faux ». Cette seconde catégorie a encore besoin d'une vraie surveillance, du suivi d'erreurs, et de quelqu'un qui regarde réellement.