FSWP DevOps Engineer
Prefira a ferramenta mais leve que comprove a afirmação. Qualquer verificação que você não puder executar aqui é relatada como NÃO EXECUTADA com o comando que o usuário pode executar (fswp-qa-engineer).
Ambientes locais
| Necessidade | Ferramenta |
|---|---|
| WordPress completo no Docker, testes PHP, múltiplos plugins/temas montados | @wordpress/env (wp-env) |
| Site descartável instantâneo no navegador ou via Node, testes de fumaça, demonstrações compartilháveis | WordPress Playground, configurado com um Blueprint |
| Pilha local existente que o usuário já executa | Use a dela; não adicione uma segunda |
wp-env (precisa de Docker e Node): a partir da raiz do projeto execute npx @wordpress/env start. Configure com .wp-env.json:
{
"core": null,
"phpVersion": "8.2",
"plugins": [ "." ],
"themes": [],
"config": { "WP_DEBUG": true, "WP_DEBUG_LOG": true }
}
Comandos úteis: npx @wordpress/env run cli wp plugin list, ... stop, ... clean, ... destroy. Use para verificar caminhos de ativação, desativação, desinstalação e atualização que o fswp-qa-engineer não consegue verificar estaticamente.
Playground: um Blueprint é um JSON que descreve o site:
{
"$schema": "https://playground.wordpress.net/blueprint-schema.json",
"landingPage": "/wp-admin/",
"preferredVersions": { "php": "8.3", "wp": "latest" },
"steps": [ { "step": "login" } ]
}
Adicione etapas como instalar um plugin ou tema, escrever arquivos e definir opções; leia os nomes de etapas atuais na documentação do Playground antes de criar. O Playground é rápido, mas não é um servidor completo: não o use como evidência para comportamento de cron, e-mail ou operações pesadas de sistema de arquivos.
Lista de etapas, tipos de recurso e a tabela completa de comandos: references/blueprints-and-cli.md.
Operações de linha de comando (WP-CLI)
Operações do site a partir de um 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. Regras: execute wp db export antes de qualquer comando destrutivo; sempre use --dry-run em um search-replace primeiro; use --skip-plugins --skip-themes ao depurar erros de carregamento; execute como o usuário web ou com --allow-root apenas em ambientes descartáveis. (WP-CLI é um projeto da WordPress Foundation; este plugin o menciona descritivamente.)
Padrões de código (PHPCS)
Instale com 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 o que pode com segurança (revise o diff). fswp-qa-engineer/scripts/setup_toolchain.sh instala PHPCS e PHPStan sem Composer para ambientes que não o têm.
Análise estática (PHPStan)
phpstan.neon com php-stubs/wordpress-stubs como bootstrap (ou a extensão szepeviktor/phpstan-wordpress), nível 5 como limite, nível maior para código novo. Defina como stubs as constantes do projeto que o WordPress ou o plugin definem em tempo de execução. Um arquivo de linha de base é aceitável para código legado, nunca para código novo.
Testes
- Testes PHP unitários e de integração:
wp-phpunit/wp-phpunitcomyoast/phpunit-polyfills, gerados porwp scaffold plugin-tests; execute em wp-env. UseWP_UnitTestCasepara testes que precisam do WordPress. - JavaScript:
@wordpress/scripts(wp-scripts build,start,lint-js,lint-style,test-unit-js,test-e2e). - Ponta a ponta: Playwright com os helpers e2e do WordPress contra wp-env, para fluxos importantes (salvar configurações, inserção de bloco, caminho de checkout).
Esboço de CI (reservado para trabalho no GitHub)
A ordem que um pipeline deve seguir: instalar, PHPCS, PHPStan, testes PHP no PHP mínimo e máximo, lint/build/teste JS, empacotar, enviar artefato. Não crie arquivos de workflow até que a integração com GitHub esteja ativada (fswp-developer/references/github-foundation.md).