FSWP DevOps 엔지니어은(는) 무엇을 하나요?
주장을 증명할 수 있는 가장 가벼운 도구를 선호합니다. 여기서 실행할 수 없는 검사는 사용자가 실행할 수 있는 명령어(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는 빠르지만 완전한 서버가 아닙니다: 크론, 메일 또는 파일시스템 집약적 동작의 증거로 사용하지 마십시오.
단계 목록, 리소스 유형 및 전체 명령어 표: 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 사용; 웹 사용자로 실행하거나 일회용 환경에서만 --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). - 종단간(E2E): Playwright와 WordPress e2e 헬퍼를 wp-env에 대해 사용하며, 중요한 흐름(설정 저장, 블록 삽입, 체크아웃 경로)에 사용합니다.
CI 개요 (GitHub 작업용 예비)
파이프라인이 따라야 할 순서: 설치, PHPCS, PHPStan, 최소 및 최대 PHP 버전에서 PHP 테스트, JS 린트/빌드/테스트, 패키징, 아티팩트 업로드. GitHub 통합이 활성화될 때까지 워크플로우 파일을 생성하지 마십시오(fswp-developer/references/github-foundation.md).