fswp-devops-engineer

FSWP DevOps Engineer

Privilégiez l'outil le plus léger qui prouve l'affirmation. Toute vérification que vous ne pouvez pas exécuter ici est signalée comme NON EFFECTUÉE avec la commande que l'utilisateur peut exécuter (fswp-qa-engineer).

Environnements locaux

Besoin	Outil
WordPress complet dans Docker, tests PHP, plusieurs plugins/thèmes montés	@wordpress/env (wp-env)
Site jetable instantané dans le navigateur ou via Node, tests rapides, démos partageables	WordPress Playground, configuré avec un Blueprint
Stack locale existante que l'utilisateur utilise déjà	Utilisez la leur ; n'en ajoutez pas une seconde

wp-env (nécessite Docker et Node) : depuis la racine du projet, exécutez npx @wordpress/env start. Configurez avec .wp-env.json :

{
  "core": null,
  "phpVersion": "8.2",
  "plugins": [ "." ],
  "themes": [],
  "config": { "WP_DEBUG": true, "WP_DEBUG_LOG": true }
}

Commandes utiles : npx @wordpress/env run cli wp plugin list, ... stop, ... clean, ... destroy. Utilisez-le pour vérifier les chemins d'activation, de désactivation, de désinstallation et de mise à niveau que fswp-qa-engineer ne peut pas vérifier statiquement.

Playground : un Blueprint est un JSON qui décrit le site :

{
  "$schema": "https://playground.wordpress.net/blueprint-schema.json",
  "landingPage": "/wp-admin/",
  "preferredVersions": { "php": "8.3", "wp": "latest" },
  "steps": [ { "step": "login" } ]
}

Ajoutez des étapes telles que l'installation d'un plugin ou d'un thème, l'écriture de fichiers et la définition d'options ; lisez les noms des étapes actuelles dans la documentation de Playground avant de les rédiger. Playground est rapide mais n'est pas un serveur complet : ne l'utilisez pas comme preuve pour le comportement lié à cron, aux e-mails ou aux opérations lourdes sur le système de fichiers.

Listes des étapes, types de ressources et table complète des commandes : references/blueprints-and-cli.md.

Opérations en ligne de commande (WP-CLI)

Opérations sur le site depuis un shell : wp plugin install|activate|deactivate|delete, wp theme ..., wp option get|update, wp post ..., wp user ..., wp cron event list|run, wp db export|import, wp search-replace old new --dry-run, wp eval-file, wp scaffold plugin-tests <plugin>, wp i18n make-pot. Règles : faites un wp db export avant toute commande destructive ; effectuez toujours un --dry-run pour un search-replace en premier ; utilisez --skip-plugins --skip-themes lors du débogage d'erreurs de chargement ; exécutez en tant qu'utilisateur web ou avec --allow-root uniquement dans des environnements jetables. (WP-CLI est un projet de la WordPress Foundation ; ce plugin y fait référence de manière descriptive.)

Standards de codage (PHPCS)

Installez avec Composer : wp-coding-standards/wpcs, dealerdirect/phpcodesniffer-composer-installer, phpcompatibility/phpcompatibility-wp. Fichier .phpcs.xml.dist minimal :

<?xml version="1.0"?>
<ruleset name="Project">
  <file>.</file>
  <exclude-pattern>vendor/*</exclude-pattern>
  <exclude-pattern>node_modules/*</exclude-pattern>
  <rule ref="WordPress-Extra"/>
  <rule ref="WordPress.WP.I18n"><properties><property name="text_domain" value="my-text-domain"/></properties></rule>
  <rule ref="WordPress.NamingConventions.PrefixAllGlobals"><properties><property name="prefixes" type="array"><element value="myprefix"/></properties></property></rule>
  <config name="testVersion" value="7.4-"/>
  <rule ref="PHPCompatibilityWP"/>
</ruleset>

phpcs fournit les rapports ; phpcbf corrige ce qu'il peut en toute sécurité (vérifiez le diff). fswp-qa-engineer/scripts/setup_toolchain.sh installe PHPCS et PHPStan sans Composer pour les environnements qui en manquent.

Analyse statique (PHPStan)

phpstan.neon avec php-stubs/wordpress-stubs comme bootstrap (ou l'extension szepeviktor/phpstan-wordpress), niveau 5 comme seuil, plus élevé pour le nouveau code. Définissez les constantes du projet que WordPress ou le plugin définit à l'exécution. Un fichier de base est acceptable pour le code existant, jamais pour le nouveau code.

Tests

• Tests unitaires et d'intégration PHP : wp-phpunit/wp-phpunit avec yoast/phpunit-polyfills, générés par wp scaffold plugin-tests ; exécutez dans wp-env. Utilisez WP_UnitTestCase pour les tests qui ont besoin de WordPress.
• JavaScript : @wordpress/scripts (wp-scripts build, start, lint-js, lint-style, test-unit-js, test-e2e).
• De bout en bout : Playwright avec les helpers e2e WordPress contre wp-env, pour les flux importants (sauvegarde de réglages, insertion de blocs, parcours de paiement).

Aperçu CI (réservé au travail GitHub)

L'ordre qu'un pipeline doit suivre : installation, PHPCS, PHPStan, tests PHP sur PHP min et max, JS lint/build/test, packaging, téléversement d'artefact. Ne créez pas de fichiers de workflow tant que l'intégration GitHub n'est pas activée (fswp-developer/references/github-foundation.md).