retour arrière

Faire pointer current sur une release encore présente sur le disque, puis redémarrer le service : ln -sfn /var/www/exemple.fr/releases/2026-08-01T09-12-03 /var/www/exemple.fr/current, puis systemctl restart api-exemple. Deux commandes, les mêmes qu'au déploiement, avec l'autre cible. Reconstruire depuis un commit ancien n'est pas un retour arrière : cela refait passer les dépendances, la chaîne d'outils et l'horloge par un chemin que personne n'a testé. Et le retour ne ramène pas le système dans son état précédent, seulement le code. Une migration appliquée par la nouvelle version reste appliquée : si elle a supprimé une colonne, l'ancien code revient sur un schéma qui n'est plus le sien et échoue là où il la lit. shared/ n'est dans aucune release. Les caches des navigateurs non plus : un index.html en cache réclame des fichiers hachés que la release précédente n'a jamais contenus. D'où la règle : une migration destructrice et le code qui en dépend ne se déploient pas ensemble.