Autoload, tests et livraison reproductible

Comprendre le mécanisme

Composer résout les contraintes de dépendances et enregistre les versions choisies dans composer.lock. Pour une application, install réutilise ce verrou ; update le recalcule. L’autoload PSR-4 associe préfixes de namespaces et répertoires : le nom, la casse et le chemin doivent correspondre, surtout après passage sur Linux. Les extensions PHP sont des exigences de plateforme ; une bibliothèque Composer ne remplace pas un pilote PDO absent.

Raisonner et vérifier

Une suite de tests combine logique unitaire, intégration de persistance et parcours HTTP. Analyse statique et tests détectent des défauts différents. Construisez l’artefact depuis une révision identifiée, vérifiez les exigences de plateforme puis préparez les caches sur la cible. Une vérification HTTP du site reste nécessaire : le PHP du serveur web peut différer du CLI. Prévoyez une procédure de retour applicatif et une stratégie distincte pour la compatibilité des migrations.

Installer les versions réellement verrouillées

composer install réutilise normalement les versions résolues dans le lock existant ; composer update peut modifier cette résolution selon les contraintes. Le lock rend les dépendances plus reproductibles, mais ne prouve pas leur sécurité ni la présence des extensions natives. Conservez-le avec la release et vérifiez l’environnement cible. Une installation globale d’outil non suivie peut produire un autre résultat que la CI sur le même code.

Ce que l’analyse statique apporte

PHPStan examine les contrats et usages de types sans rejouer tous les parcours métier. Il peut détecter un appel incompatible que les tests n’ont jamais exécuté, mais ne prouve pas toutes les règles d’autorisation ou l’absence de vulnérabilité. Fixez version, niveau et chemins analysés. Complétez le rapport par des tests de comportement et une revue des frontières ; chaque technique doit annoncer le périmètre qu’elle vérifie réellement.

Les refus sont des comportements à tester

Un parcours nominal ne démontre pas ce que le service fait sur une entrée invalide ou une permission insuffisante. Écrivez le refus attendu et l’effet qui doit rester absent. Pour un import, vérifiez qu’un fichier rejeté ne laisse pas d’écriture métier partielle. Les classes de test doivent représenter les distinctions du contrat, comme absence, mauvais type et objet tiers, plutôt qu’un nombre arbitraire d’exemples similaires.

Faire remonter le résultat au bon appelant

Une CI se fonde notamment sur les codes de sortie des processus. Afficher un message d’erreur puis terminer avec un succès peut laisser passer une régression. Examinez les branches de shell qui ajoutent true ou ignorent une exception. Le contrôle doit produire un résultat exploitable par l’étape suivante. Un test utile introduit volontairement un défaut connu et vérifie que la pipeline refuse effectivement l’artefact.

Identifier le contenu servi

Le nom d’un dossier ne suffit pas à identifier une release exacte. Associez l’artefact à un commit ou une empreinte et vérifiez que le serveur expose bien cette version après bascule. Une copie réussie peut encore laisser un lien current, un cache ou un processus sur l’ancien code. Le health check doit donc relier comportement attendu et identité de release, pas seulement constater qu’un serveur répond quelque chose.

Comparer les runtimes CLI et web

Le binaire PHP du shell et celui du serveur web peuvent charger des configurations et extensions différentes. La présence de pdo_mysql dans le CLI ne démontre pas celle du processus qui traite HTTP. Vérifiez chaque contexte avec les outils de diagnostic adaptés et un accès protégé. Le DSN, le driver et l’environnement applicatif doivent aussi correspondre : l’erreur could not find driver ne se corrige pas par une migration SQL.

Choisir un contrôle de santé représentatif

Un fichier statique peut être servi alors que l’application ou sa base est indisponible. Définissez précisément la garantie du contrôle : démarrage du framework, version active et dépendances nécessaires au parcours testé. Évitez d’y déclencher une mutation réelle ou d’y publier des secrets. Un échec doit aider à localiser la frontière en cause, tandis qu’un succès doit rester limité à ce qui a réellement été observé.

Revenir au code et reprendre les données

Un retour de code peut rétablir un ancien artefact, mais ne remet pas automatiquement la base dans son état précédent. Une migration ou de nouvelles écritures peuvent rendre cet ancien code incompatible. Concevez les changements de schéma avec une stratégie de compatibilité et de reprise. Testez le scénario de bascule et son retour sur des données représentatives ; un simple changement de lien symbolique ne prouve pas la restaurabilité.

Distribuer sans inclure les secrets

Les credentials de production doivent suivre un canal et un périmètre d’accès adaptés. Les copier dans une image ou un artefact public peut les rendre récupérables, même si une étape ultérieure les retire de la vue finale. Vérifiez aussi la casse des chemins PSR-4 : un fichier toléré sur un poste local peut ne plus être trouvé sous Linux. Le namespace, le nom de classe et le chemin doivent respecter le contrat d’autoload.

Démontrer une restauration utile

Une sauvegarde présente sur disque n’est pas encore une preuve de reprise. Restaurez-la dans un environnement isolé, mesurez le délai et vérifiez les invariants métier importants. Conservez les versions d’outils et les préconditions nécessaires. L’exercice doit aussi considérer les secrets anciens qui pourraient être réintroduits. Un rapport de succès du producteur de sauvegarde ne démontre pas à lui seul toutes ces propriétés chez le consommateur.

Atelier guidé : lire, expliquer et vérifier le code

php vendor/bin/phpstan analyse || true
printf 'quality step finished
' 

La commande de l’exercice enchaîne PHPStan avec une branche de secours qui retourne true. Si l’analyse échoue, cette branche peut faire terminer la séquence avec un statut de succès. Le texte affiché ensuite ne répare aucun type. Une pipeline qui regarde seulement le code de sortie peut donc considérer l’étape comme réussie malgré les diagnostics visibles.

Retirez ce masquage dans le laboratoire, introduisez un appel de méthode incompatible puis examinez le statut retourné au shell. Vérifiez ensuite que l’étape de livraison est réellement bloquée. Gardez une fixture nominale afin de distinguer un contrôle correctement discriminant d’un job qui échoue toujours. Conservez enfin la version et la configuration de PHPStan pour rendre la preuve reproductible entre le poste et la CI.

PSR-4 : namespace et casse du chemin en production

Mapping PSR-4 : "App\\": "src/"
Classe : App\Payment\AuthorizeHandler
Fichier : src/payment/AuthorizeHandler.php

Avec une correspondance App\ vers src/, les segments de namespace et le nom de classe déterminent le chemin PSR-4 attendu. App\Payment\AuthorizeHandler correspond à src/Payment/AuthorizeHandler.php avec la casse prescrite. Un répertoire payment peut sembler fonctionner sur un système de fichiers permissif et échouer sur Linux sensible à la casse.

Vérifiez déclaration, préfixe Composer et chemin réel. Le scénario exclut une classmap autoritative : ne choisissez donc pas une explication fondée sur un mode d’autoload différent de celui annoncé. Corrigez la casse dans le dépôt puis régénérez l’autoload selon le processus normal de build.

Si le système local masque un renommage de casse seule, utilisez un nom temporaire dans Git pour enregistrer la transition. Exécutez un chargement de la classe dans un environnement représentatif avant release. Évitez les require manuels ajoutés au hasard, qui masqueraient le contrat de nommage au lieu de le corriger.

Points de vigilance : L’autoload PSR-4 fonctionne sans framework. PSR-4 associe les noms qualifiés à des chemins, pas à un fichier monolithique. Les noms peuvent contenir des majuscules ; la correspondance de casse doit être respectée. Le chemin diffère par sa casse. Un environnement local permissif peut masquer cette erreur.