hero.vfg.lol · v2.0.0 en production

Six gestes pour rendre une bascule réversible

Une session qui part d'un audit et finit en production : figer ce qui tourne, exporter ce qui vit, déployer, migrer, tourner le secret, clore. Aucun geste spectaculaire — c'est leur ordre qui a tout sauvé.

/prototypes/apercus/ VFG Hero · 2026-10-05 6 gestes · 1 quasi-effacement évité
⚠️ le piège invisible

La base de données vivait dans un dossier éphémère du conteneur, alors que le volume censé la préserver était monté sur un dossier voisin.

Conséquence : elle n'était jamais sauvegardée, et le script de sauvegarde de la flotte archivait un volume vide. Le geste de routine qui devait protéger les données les aurait regardées disparaître au premier redéploiement. Quatre mois de vie du personnage — sans un seul message d'erreur.

Les six gestes, dans l'ordre

Chaque étape mesurée avant d'être franchie. Aucune déduction depuis la prose.

1

Figer ce qui tourne

Comparaison des fichiers réellement servis en production avec l'historique du dépôt → un commit précis de juin. Le tag de release existant était deux commits trop ancien : un retour dessus n'aurait pas restauré la vraie version.

Geste : créer un tag de retour fidèle, hors du motif qui déclenche les automatisations — un gel ne relance rien.
2

Exporter ce qui vit

Base copiée sans arrêter le service, empreinte vérifiée, contenu relu (niveau, expérience, quêtes) pour emporter du réel et pas une coquille vide.

Pourquoi : c'est ce geste qui a révélé le piège ci-dessus. Un second export suit juste avant la bascule, par principe.
3

Déployer

Chaîne de déploiement morte (transfert FTP en échec à chaque poussée) remplacée par la chaîne vivante : image construite, publiée, puis démarrée à distance via le script canonique.

Corrigé au passage : le montage du volume, pour que la base soit enfin persistée.
4

Migrer

Le « réimport » n'est pas un remplacement : la nouvelle version migre la base en place (migrations idempotentes) — les données survivent et se complètent.

Vérifié : niveau 7, 997 XP et 9 quêtes servis par la fiche publique après bascule.
5

Tourner le secret

Le jeton ayant été public, il est régénéré — des deux côtés (Hero et la porte d'intégration), puis les services recréés : un jeton est figé à la création du conteneur.

Preuve : nouveau jeton accepté, ancien refusé. Phrase de connexion propriétaire posée, distincte du jeton d'API.
6

Clore

Récapitulatif daté, vérifications avec leur commande, chemin de retour, prochaine action exacte. Source de l'article publiée par branche propre — pas d'envoi direct sur l'arbre partagé.

Règle : clore, c'est écrire pour celui qui reprend — pas résumer pour soi.

Avant / après

Même service, même données — deux états mesurés à une heure d'intervalle.

Avant (production)

  • Build de juin servi, ~88 jours d'uptime API
  • Jeton d'écriture exposé dans env.js
  • Page d'admin publique
  • Base non persistée (volume sur le mauvais dossier)
  • FTP en échec à chaque poussée

Après (v2.0.0)

  • Assets de la v2 servis, API redémarrée
  • env.js sans jeton · jeton tourné
  • Admin redirigée vers la connexion
  • Base persistée + migrée en place
  • Chaîne Docker unique, déployable et réversible

Contrôles de sortie

Six vérifications rejouables, toutes vertes après bascule.

ContrôleRésultat
Page env.jsaucun jeton
Écriture sans session403
Fiche publique200 · niveau 7
Page d'admin302 → connexion
Santé APIuptime faible
Frontassets v2

↩︎ Retour possible à tout moment

L'image de juin est figée dans un tag de retour ; les sauvegardes de configuration et d'environnement sont conservées à côté ; un export de la base existe hors du serveur.

deploy.sh hero-api hero-web --tag c99a0bc

La leçon n'est pas « on a livré une version ».
C'est qu'un déploiement — sans avoir mesuré ce qui tourne et où vivent les données — aurait pu effacer quatre mois de vie, sans un seul message d'erreur.
Figer, exporter, mesurer : avant d'écrire quoi que ce soit.