FSWP DevOps Engineer

Was macht FSWP DevOps Engineer?

Bevorzugen Sie das leichteste Werkzeug, das die Behauptung belegt. Jede Prüfung, die Sie hier nicht ausführen können, wird als NICHT AUSGEFÜHRT gemeldet, zusammen mit dem Befehl, den der Benutzer ausführen kann (fswp-qa-engineer).

Lokale Umgebungen

Bedarf	Werkzeug
Vollständiges WordPress in Docker, PHP-Tests, mehrere Plugins/Themes eingehängt	@wordpress/env (wp-env)
Sofort einsatzbereite, temporäre Site im Browser oder über Node, Rauchtests, teilbare Demos	WordPress Playground, konfiguriert mit einem Blueprint
Vorhandener lokaler Stack, den der Benutzer bereits ausführt	Verwenden Sie dessen; fügen Sie keinen zweiten hinzu

wp-env (benötigt Docker und Node): Führen Sie vom Projektstamm aus npx @wordpress/env start aus. Konfigurieren Sie mit .wp-env.json:

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

Nützliche Befehle: npx @wordpress/env run cli wp plugin list, ... stop, ... clean, ... destroy. Verwenden Sie es, um Aktivierungs-, Deaktivierungs-, Deinstallations- und Upgrade-Pfade zu verifizieren, die fswp-qa-engineer nicht statisch prüfen kann.

Playground: Ein Blueprint ist JSON, das die Site beschreibt:

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

Fügen Sie Schritte wie das Installieren eines Plugins oder Themes, das Schreiben von Dateien und das Setzen von Optionen hinzu; lesen Sie die aktuellen Schrittnamen in der Playground-Dokumentation, bevor Sie sie verfassen. Playground ist schnell, aber kein vollständiger Server: Verwenden Sie es nicht als Beleg für Cron-, E-Mail- oder dateisystemintensives Verhalten.

Schrittlisten, Ressourcentypen und die vollständige Befehlstabelle: references/blueprints-and-cli.md.

Kommandozeilen-Operationen (WP-CLI)

Site-Operationen von einer 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. Regeln: Führen Sie vor jedem destruktiven Befehl wp db export aus; führen Sie immer zuerst ein --dry-run bei einem search-replace durch; verwenden Sie --skip-plugins --skip-themes beim Debuggen von Lade-Fehlern; führen Sie als Web-Benutzer aus oder verwenden Sie --allow-root nur in Einweg-Umgebungen. (WP-CLI ist ein Projekt der WordPress Foundation; dieses Plugin bezieht sich deskriptiv darauf.)

Codierungsstandards (PHPCS)

Installieren mit Composer: wp-coding-standards/wpcs, dealerdirect/phpcodesniffer-composer-installer, phpcompatibility/phpcompatibility-wp. Minimale .phpcs.xml.dist:

<?xml version="1.0"?>
<ruleset name="Projekt">
  <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="mein-text-domain"/></properties></rule>
  <rule ref="WordPress.NamingConventions.PrefixAllGlobals"><properties><property name="prefixes" type="array"><element value="meinprefix"/></properties></property></rule>
  <config name="testVersion" value="7.4-"/>
  <rule ref="PHPCompatibilityWP"/>
</ruleset>

phpcs meldet; phpcbf behebt, was es sicher kann (überprüfen Sie das Diff). fswp-qa-engineer/scripts/setup_toolchain.sh installiert PHPCS und PHPStan ohne Composer für Umgebungen, die es nicht haben.

Statische Analyse (PHPStan)

phpstan.neon mit php-stubs/wordpress-stubs als Bootstrap (oder der Erweiterung szepeviktor/phpstan-wordpress), Stufe 5 als Tor, höher für neuen Code. Stub-Projektkonstanten, die WordPress oder das Plugin zur Laufzeit definieren. Eine Basisdatei ist für Legacy-Code akzeptabel, niemals für neuen Code.

Tests

• PHP-Unit- und Integrationstests: wp-phpunit/wp-phpunit mit yoast/phpunit-polyfills, generiert durch wp scaffold plugin-tests; ausführen in wp-env. Verwenden Sie WP_UnitTestCase für Tests, die WordPress benötigen.
• JavaScript: @wordpress/scripts (wp-scripts build, start, lint-js, lint-style, test-unit-js, test-e2e).
• End-to-End: Playwright mit den WordPress-E2E-Helfern gegen wp-env, für Abläufe, die wichtig sind (Einstellungen speichern, Block einfügen, Checkout-Pfad).

CI-Grundgerüst (reserviert für GitHub-Arbeiten)

Die Reihenfolge, die eine Pipeline befolgen sollte: Installieren, PHPCS, PHPStan, PHP-Tests auf min und max PHP, JS-Lint/Build/Test, Paket, Artefakt hochladen. Erstellen Sie keine Workflow-Dateien, bis die GitHub-Integration aktiviert ist (fswp-developer/references/github-foundation.md).