Ingeniero DevOps FSWP
Prefiere la herramienta más ligera que demuestre la afirmación. Cualquier comprobación que no puedas ejecutar aquí se reporta como NO EJECUTADA con el comando que el usuario puede ejecutar (fswp-qa-engineer).
Entornos locales
| Necesidad | Herramienta |
|---|---|
| WordPress completo en Docker, pruebas PHP, múltiples plugins/temas montados | @wordpress/env (wp-env) |
| Sitio instantáneo desechable en el navegador o mediante Node, pruebas rápidas, demos compartibles | WordPress Playground, configurado con un Blueprint |
| Stack local existente que el usuario ya ejecuta | Usa el suyo; no agregues un segundo |
wp-env (necesita Docker y Node): desde la raíz del proyecto ejecuta npx @wordpress/env start. Configura con .wp-env.json:
{
"core": null,
"phpVersion": "8.2",
"plugins": [ "." ],
"themes": [],
"config": { "WP_DEBUG": true, "WP_DEBUG_LOG": true }
}
Comandos útiles: npx @wordpress/env run cli wp plugin list, ... stop, ... clean, ... destroy. Úsalo para verificar rutas de activación, desactivación, desinstalación y actualización que fswp-qa-engineer no puede comprobar estáticamente.
Playground: un Blueprint es un JSON que describe el sitio:
{
"$schema": "https://playground.wordpress.net/blueprint-schema.json",
"landingPage": "/wp-admin/",
"preferredVersions": { "php": "8.3", "wp": "latest" },
"steps": [ { "step": "login" } ]
}
Agrega pasos como instalar un plugin o tema, escribir archivos y establecer opciones; lee los nombres actuales de los pasos en la documentación de Playground antes de redactar. Playground es rápido pero no es un servidor completo: no lo uses como evidencia para comportamientos relacionados con cron, correo o uso intensivo del sistema de archivos.
Listas de pasos, tipos de recursos y la tabla de comandos completa: references/blueprints-and-cli.md.
Operaciones de línea de comandos (WP-CLI)
Operaciones del sitio desde 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. Reglas: haz wp db export antes de cualquier comando destructivo; siempre ejecuta --dry-run un search-replace primero; usa --skip-plugins --skip-themes al depurar errores de carga; ejecuta como el usuario web o con --allow-root solo en entornos desechables. (WP-CLI es un proyecto de WordPress Foundation; este plugin lo referencia de forma descriptiva.)
Estándares de codificación (PHPCS)
Instala con Composer: wp-coding-standards/wpcs, dealerdirect/phpcodesniffer-composer-installer, phpcompatibility/phpcompatibility-wp. .phpcs.xml.dist mínimo:
<?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 reporta; phpcbf corrige lo que puede de forma segura (revisa el diff). fswp-qa-engineer/scripts/setup_toolchain.sh instala PHPCS y PHPStan sin Composer para entornos que carezcan de él.
Análisis estático (PHPStan)
phpstan.neon con php-stubs/wordpress-stubs como bootstrap (o la extensión szepeviktor/phpstan-wordpress), nivel 5 como puerta de entrada, más alto para código nuevo. Escribe stubs para constantes de proyecto que WordPress o el plugin definan en tiempo de ejecución. Un archivo de línea base es aceptable para código heredado, nunca para código nuevo.
Pruebas
- Pruebas unitarias y de integración PHP:
wp-phpunit/wp-phpunitconyoast/phpunit-polyfills, generado porwp scaffold plugin-tests; ejecutar en wp-env. UsaWP_UnitTestCasepara pruebas que necesiten WordPress. - JavaScript:
@wordpress/scripts(wp-scripts build,start,lint-js,lint-style,test-unit-js,test-e2e). - Punto a punto: Playwright con los ayudantes e2e de WordPress contra wp-env, para flujos importantes (guardado de ajustes, inserción de bloques, ruta de pago).
Esquema de CI (reservado para trabajo en GitHub)
El orden que debe seguir un pipeline: instalar, PHPCS, PHPStan, pruebas PHP en PHP mínimo y máximo, lint/build/test de JS, empaquetar, subir artefacto. No crees archivos de workflow hasta que la integración con GitHub esté activada (fswp-developer/references/github-foundation.md).