Doctrine

Le composer.json de chaque service avait ça dans sa section post-install-cmd : "post-install-cmd": [ "bin/console cache:clear --env=prod", "bin/console doctrine:migrations:migrate --no-interaction" ] post-install-cmd s’exécute pendant composer install, qui dans le Dockerfile de production tourne au moment du build de l’image. Il n’y a pas de base de données disponible pendant un build Docker. La commande de migration échouait silencieusement, se connectait à rien, ou était ignorée par Doctrine faute de schéma à comparer. Dans tous les cas, elle ne migrait rien. ...

Le champ de recherche de la médiathèque renvoyait des résultats en 800 millisecondes en staging. En production, il y avait quarante fois plus de lignes. Le plan d’exécution révélait un sequential scan: aucun index sollicité, aucune façon d’y remédier avec un B-tree classique. L’équipe produit voulait aussi une recherche multi-mots: taper “interview président”, obtenir des résultats contenant les deux termes. Une requête LIKE avec des wildcards n’a pas de manière propre d’exprimer ça sans conditions indépendantes multiples, chacune nécessitant son propre scan. ...

Chaque mise à jour de contenu sur la plateforme crée une révision. C’est délibéré : les éditeurs ont besoin d’un historique sur lequel ils peuvent revenir, et la plateforme a besoin d’une piste d’audit. Ce que personne n’avait anticipé, c’était le rythme. Certains articles passent par quarante sauvegardes en un seul après-midi. Une pièce à fort trafic accumule des centaines de révisions sur sa durée de vie. Après quelques mois, la table de révisions avait plusieurs millions de lignes. ...

Un timestamp qui revient de la base de données avec une heure de décalage. Pas à chaque fois. Uniquement quand le serveur de dev tourne en Europe/Paris et que la CI tourne en UTC. Le genre de bug qui disparaît quand on le cherche et qui revient en production un vendredi soir. Le problème n’est pas dans la logique métier. Il est dans ce que Doctrine fait discrètement avec les dates. ...