DOCUMENT · 8.8 KB

qa/e2e-xserver.md

Workspace snapshot · 09/04 13:33

E2E 実行手順（実サーバー版）— pengi-n.jp/tmp/test / Xserver

e2e-commands.md（Playground / SQLite 版）の実サーバー版。こちらが本命。

理由: 植木さんの指摘どおり、日本の制作現場はレンタルサーバー中心で、実際に使われるのは wp-cli + MySQL の経路。Playground は SQLite なので wp db export / wp search-replace が想定どおり動く保証がなく（e2e-commands.md Block 0 の能力ゲート）、そもそも検証したい環境と違う。実サーバーで通ったE2Eの方が、証拠として強い。

このファイルは未実行。 シェル実行の許可が下りた時点で上から順に実行する。

0. 使用許可と隔離条件（毎回読む）

植木さんからの許可: 「pengi-n.jp/tmp/test/ のなか自由に使っていいよ」「一時ファイル終わったら削除してね」

したがって:

触ってよいのは /tmp/test/ 配下だけ。 その外のディレクトリ・DB・ドメイン設定には一切触れない。
既存のWordPress、既存のDB、他プロジェクトを読み書きしない。
DNS設定・ドメイン設定・メール設定を変更しない。
サーバーパネルの設定を変更しない（SSH有効化が未設定なら、自分で有効化せず植木さんに確認する）。
**終了後、作成したディレクトリ・DB・ダンプファイルをすべて削除する。**削除まで含めて1回の作業。
作業ログに認証情報を書かない。DBパスワードは wp config create --prompt 等で対話入力し、コマンド履歴へ平文で残さない。

1. 接続と前提確認（読み取りのみ）

# SSHは公開鍵認証のみ（エックスサーバー仕様）。鍵が未登録なら、ここで止めて確認する。
ssh -i ~/.ssh/<鍵> <アカウント>@<サーバー> -p 10022

cd ~/pengi-n.jp/public_html/tmp/test 2>/dev/null || echo "パスを確認する"
pwd
php -v | head -1
which wp || echo "wp-cli 無し → 手順2で導入"
df -h . | tail -1

PASS条件: /tmp/test 配下に入れて、PHPのバージョンが取れること。

2. WP-CLI の用意（無い場合）

一次情報で確認済みのとおり、レンタルサーバーはWP-CLIを標準提供していない。 /tmp/test 配下にphar を置いて、そこからだけ使う（サーバー全体には入れない）。

curl -sO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
alias wp="php $(pwd)/wp-cli.phar"
wp --version

PASS条件: wp --version が返る。ここが通らなければ Step 5-B（WP-CLIなし経路）の検証へ切り替える。 これ自体が検証結果なので、通らなかった事実も記録する。

3. 移行元サイトを作る（型C の移行元）

DBはサーバーパネルで作成済みのものを使う（新規作成が必要なら植木さんに確認）。

mkdir -p old && cd old
wp core download --locale=ja
wp config create --dbname=<DB> --dbuser=<USER> --prompt=dbpass
wp core install --url="https://pengi-n.jp/tmp/test/old" --title="E2E移行元" \
  --admin_user=e2eadmin --prompt=admin_password --admin_email=<自分の確認用アドレス>

wp rewrite structure '/%postname%/' --hard
wp post create --post_title="記事1" --post_status=publish \
  --post_content='<a href="https://pengi-n.jp/tmp/test/old/about/">内部リンク</a>'
wp post create --post_type=page --post_title="About" --post_name=about --post_status=publish
wp option update pengin_test_serialized --format=json \
  '{"url":"https://pengi-n.jp/tmp/test/old/path","nested":{"esc":"https:\\/\\/pengi-n.jp\\/tmp\\/test\\/old\\/x"}}'
wp option update blog_public 0     # 検索避けを意図的に残す（型Dの事故を検出できるか見るため）
curl -sI https://pengi-n.jp/tmp/test/old/ | head -n 3

PASS条件: トップが 200。投稿件数を控える（手順9・11で照合）。

4. Step 2 相当 — 読み取りのみの調査

wp core version ; wp option get siteurl ; wp option get home
wp option get blog_public ; wp option get permalink_structure
wp db prefix ; wp plugin list --status=active
wp post list --post_type=any --format=count
wp db size --human-readable
wp config list --strict | grep -Ei 'WP_SITEURL|WP_HOME|WP_CONTENT_URL|COOKIE_DOMAIN|FORCE_SSL|WP_CACHE'

PASS条件: 全項目が取得でき、書き込み系コマンドが1つも混ざっていない。

5. Step 4 相当 — バックアップと復元可能性

wp db export ../backup-pre-migration.sql
ls -l ../backup-pre-migration.sql
tail -c 200 ../backup-pre-migration.sql     # Dump completed 相当が見えるか

復元可能性の確認は使い捨ての別DBへ入れる。本番相当のDBへ試し戻ししない。

# 別DB（検証用）が用意できる場合のみ実施。無ければ SKIP と記録する
wp db import ../backup-pre-migration.sql --dbname=<検証用DB>   # 相当の手順
wp post list --post_type=any --format=count   # 手順4と一致するか

PASS条件: ダンプが0バイトでなく末尾まで書けている。復元後の件数が一致する（できない場合はSKIPと明記）。

6. Step 5 — dry-run 6形式と確認ゲート（最重要）

移行先は https://pengi-n.jp/tmp/test/new。

OLD=pengi-n.jp/tmp/test/old ; NEW=pengi-n.jp/tmp/test/new
SR="--all-tables-with-prefix --precise --report-changed-only --skip-columns=guid"

wp search-replace "https://$OLD" "https://$NEW" $SR --dry-run
wp search-replace "http://$OLD"  "https://$NEW" $SR --dry-run
wp search-replace "//$OLD"       "//$NEW"       $SR --dry-run
wp search-replace "https:\\/\\/$OLD" "https:\\/\\/$NEW" $SR --dry-run
wp search-replace "http:\\/\\/$OLD"  "https:\\/\\/$NEW" $SR --dry-run
wp search-replace "\\/\\/$OLD"       "\\/\\/$NEW"       $SR --dry-run

# DBが変わっていないことを確認する
wp option get pengin_test_serialized --format=json

PASS条件:

各コマンドが変更予定件数を報告する
pengin_test_serialized の値が old のまま。1文字でも new に変わっていたらE2E失敗。

7. 同意後に実行（再ダンプしてから）

wp db export ../pre-replace.sql
# 上の6コマンドを --dry-run なしで同じ順序で実行
wp cache flush ; wp rewrite flush --hard ; wp transient delete --all
wp option get pengin_test_serialized --format=json    # JSONとして壊れていないか
wp db search "$OLD" --all-tables-with-prefix --stats   # 0件が正常

PASS条件: シリアライズ値が壊れずに new へ変わり、旧URLの残存が0件。

8-10. 移行先で検証

cd .. && cp -r old new && cd new
wp option update siteurl "https://pengi-n.jp/tmp/test/new"
wp option update home    "https://pengi-n.jp/tmp/test/new"
wp rewrite flush --hard

curl -sI  https://pengi-n.jp/tmp/test/new/ | head -n 5
curl -sIL https://pengi-n.jp/tmp/test/new/ | grep -i '^location'
curl -s   https://pengi-n.jp/tmp/test/new/ | grep -Eio 'noindex|tmp/test/old' | sort -u
curl -s   https://pengi-n.jp/tmp/test/new/robots.txt
curl -sI  https://pengi-n.jp/tmp/test/new/about/ | head -n 1
curl -sI  https://pengi-n.jp/tmp/test/new/wp-login.php | head -n 1
wp option get blog_public

PASS条件: トップと /about/ が 200、リダイレクトループなし、旧URL残存なし、 wp-login.php が 200、そして blog_public が 0 のままであることを検出できる （このE2Eでは意図的に残しているので、Disallow: / が出るのが正しい）。

11. ロールバック

wp db import ../pre-replace.sql
wp option get siteurl                          # old に戻るか
wp post list --post_type=any --format=count    # 手順4と一致するか

PASS条件: siteurl が old に戻り、件数が一致する。

12. 後片付け（必ず実行・省略しない）

cd ~ && rm -rf <作業ディレクトリ>/old <作業ディレクトリ>/new
rm -f <作業ディレクトリ>/backup-pre-migration.sql <作業ディレクトリ>/pre-replace.sql
rm -f <作業ディレクトリ>/wp-cli.phar
# 検証用に作成したDBがあれば削除（サーバーパネル側の操作が必要なら植木さんへ依頼）
history -c 2>/dev/null

削除まで終えて初めて1回の作業が完了する。残したまま次へ進まない。

結果の記録

workspace/qa/e2e-result.md に、手順ごとに「実行コマンド / 出力の要点 / PASS・FAIL・SKIP（理由）」を書く。 FAILがあれば、それが手順の欠陥なら SKILL.md か RUNBOOK.md を直し、 E2E側の書き方の問題ならこのファイルを直して再実行する。

全PASSして初めて SKILL_PUBLISH を申請する。