FSWP DevOps Engineer は何をしますか？
主張を証明するには最も軽量なツールを優先してください。ここで実行できないチェックは、ユーザーが実行できるコマンドとともに「未実行 (NOT RUN)」として報告します（詳細は fswp-qa-engineer を参照）。
ローカル環境
| ニーズ | ツール |
|---|---|
| Docker上でフルWordPress、PHPテスト、複数プラグイン/テーマのマウント | @wordpress/env (wp-env) |
| ブラウザまたはNode経由で即席の使い捨てサイト、スモークテスト、共有可能なデモ | WordPress Playground（Blueprintで構成） |
| ユーザーが既に実行している既存のローカルスタック | そちらを使用する；新たに追加しない |
wp-env（DockerとNodeが必要）：プロジェクトルートから npx @wordpress/env start を実行。設定は .wp-env.json で行います：
{
"core": null,
"phpVersion": "8.2",
"plugins": [ "." ],
"themes": [],
"config": { "WP_DEBUG": true, "WP_DEBUG_LOG": true }
}
便利なコマンド：npx @wordpress/env run cli wp plugin list, ... stop, ... clean, ... destroy。これを使用して、fswp-qa-engineer では静的にチェックできない有効化、無効化、アンインストール、アップグレードパスを検証します。
Playground: Blueprintはサイトを記述するJSONです：
{
"$schema": "https://playground.wordpress.net/blueprint-schema.json",
"landingPage": "/wp-admin/",
"preferredVersions": { "php": "8.3", "wp": "latest" },
"steps": [ { "step": "login" } ]
}
プラグインやテーマのインストール、ファイルの書き込み、オプション設定などのステップを追加します。作成前にPlaygroundのドキュメントで現在のステップ名を確認してください。Playgroundは高速ですが、完全なサーバーではありません。cron、メール、ファイルシステムを多用する動作の証拠として使用しないでください。
ステップ一覧、リソースタイプ、完全なコマンドテーブルは references/blueprints-and-cli.md を参照してください。
コマンドライン操作（WP-CLI）
シェルからのサイト操作：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。ルール：破壊的なコマンドの前には必ず wp db export を実行；search-replace は常に最初に --dry-run で実行；ロードエラーのデバッグ時には --skip-plugins --skip-themes を使用；Webユーザーとして実行するか、使い捨て環境でのみ --allow-root を使用する。（WP-CLIはWordPress Foundationのプロジェクトです；このプラグインでは説明目的で言及しています。）
コーディング規約（PHPCS）
Composerでインストール：wp-coding-standards/wpcs, dealerdirect/phpcodesniffer-composer-installer, phpcompatibility/phpcompatibility-wp。最小限の .phpcs.xml.dist：
<?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 でレポート；phpcbf で安全に修正可能な箇所を修正（差分を確認）。fswp-qa-engineer/scripts/setup_toolchain.sh は、Composerがない環境向けにPHPCSとPHPStanをインストールします。
静的解析（PHPStan）
phpstan.neon で php-stubs/wordpress-stubs をブートストラップとして使用（または szepeviktor/phpstan-wordpress 拡張）、レベル5をゲートに、新しいコードにはより高レベルを設定。WordPressまたはプラグインが実行時に定義するプロジェクト定数はスタブ化します。ベースラインファイルはレガシーコードには許容されますが、新しいコードには使用しません。
テスト
- PHPユニットテストおよび統合テスト：
wp-phpunit/wp-phpunitとyoast/phpunit-polyfillsをwp scaffold plugin-testsで生成；wp-env内で実行。WordPressが必要なテストにはWP_UnitTestCaseを使用。 - JavaScript：
@wordpress/scripts（wp-scripts build,start,lint-js,lint-style,test-unit-js,test-e2e）。 - エンドツーエンド： PlaywrightとWordPress e2eヘルパーをwp-envに対して使用。重要なフロー（設定保存、ブロック挿入、チェックアウトパス）に適用。
CIの概要（GitHub作業用に予約）
パイプラインが従うべき順序：インストール、PHPCS、PHPStan、最小および最大PHPでのPHPテスト、JSリント/ビルド/テスト、パッケージ化、アーティファクトのアップロード。GitHubインテグレーションが有効になるまでワークフローファイルは作成しないでください（fswp-developer/references/github-foundation.md を参照）。