スロット攻略 プロジェクトドキュメント

Appearance

本番環境デプロイ（slotkouryaku.com） ​

概要 ​

開発環境（core_src）からビルドした成果物（core_YYYYMMDD_HHMMSS）を、本番環境（slotkouryaku.com）へデプロイする手順です。ステージング環境デプロイと同じ 3 ステップ構成（build → deploy → activate）です。

このページは 本番作業時の入口 です。通常の本番反映ではこのページを正本として扱い、接続・同期・障害対応・過去の移行記録は下表から目的別に参照します。

本番作業の入口 ​

目的参照先位置づけ
本番へコードを反映するこのページ本番デプロイの正本
ステージングで先に確認するステージング環境デプロイ本番と同じ build → deploy → activate 構成の検証先
デプロイ後に動作確認するデプロイ後チェックリストデプロイ後テスター向けの確認項目（本番操作は明示指示時のみ）
本番サーバーへ SSH 接続する本番環境への接続方法config/local.env と ConoHa WING の接続情報確認
本番で WP-CLI を使うWP-CLI 接続手順 / WP-CLI 導入手順管理コマンド・シード・確認用
本番 DB をローカルへ同期するDB 同期安全ガイド / DB 同期ローカル上書きを伴うため安全ガイドを先に確認
本番ファイルをローカルへ同期本番→ローカル ファイル同期ガイドテーマ・プラグイン・uploads の rsync 手順
障害予防・初動対応を確認するサイト停止防止ガイド本番反映前後の確認観点と障害時の調査入口
過去の本番移行記録を見る本番移行手順マニュアル参考保存。現役手順ではなく、緊急リカバリや経緯確認でのみ参照

作業前の確認順 ​

前提条件 ​

  • ローカル環境でのテスト・品質チェック完了（または Actions の CI Quality Gate で 反映する HEAD を検証済み）
  • ステージングでの動作確認完了
  • デプロイ設定ファイルの準備（config/local.env）

CI は Plan B のため、追加 push（synchronize）では品質ゲートが自動起動しません。本番反映直前に CI 運用方針 に沿い、Run workflow またはローカル composer quality-check:full で対象 SHA を検証してください。

確認順 ​

本番作業前は、次の順で確認します。

  1. 反映対象の git HEAD で品質ゲートを検証済みか確認する（Actions → CI Quality Gate → Run workflow、または composer quality-check:full）。
  2. 反映対象がステージングで確認済みかを ステージング環境デプロイ で確認する。
  3. config/local.env と SSH 接続情報を 本番環境への接続方法 に沿って確認する。
  4. DB やファイルをローカルへ同期する作業が必要な場合は、デプロイ手順ではなく DB 同期安全ガイド と ファイル同期ガイド を先に確認する。
  5. 障害時の切り戻し・確認観点を サイト停止防止ガイド とこのページの ロールバック で確認する。

./bin/deploy-all.sh / ./bin/deploy-all-ftps-zip.sh はビルド前にこの確認を強制します（詳細は 品質ゲート確認）。

設定手順 ​

1. config/local.env の作成 ​

bash
cp config/local.env.example config/local.env
nano config/local.env

2. 設定する項目 ​

変数説明
DEPLOY_HOST本番サーバーのホスト名または IP
DEPLOY_PORTSSH ポート（省略時は 22）
DEPLOY_USERSSH ログインユーザー名
DEPLOY_SSH_KEY秘密鍵のパス（例: ~/.ssh/your-private-key.pem）
DEPLOY_REMOTE_PATH本番のテーマ直下のフルパス（core_* を置くディレクトリ）
LEGAL_OPERATOR_NAME法務文書シード用の公開事業者名（屋号。build.sh 必須。未設定だとビルド失敗）
LEGAL_PUBLIC_CONTACT_EMAIL法務文書シード用の公開メール（build.sh 必須）

ローカル _src で法務ページを自動作成したい場合は、上記を設定したうえで ./bin/generate-legal-operator-local.sh を実行する（LegalOperatorBuildValues.local.php を生成。gitignore 対象）。

DEPLOY_REMOTE_PATH の例:

/home/conoha/public_html/slotkouryaku.com/wp-content/themes/cocoon-child-master/myCustom

3. パーミッション ​

bash
chmod 600 config/local.env

デプロイ手順 ​

品質ゲート確認（deploy-all） ​

./bin/deploy-all.sh と ./bin/deploy-all-ftps-zip.sh は、build.sh の前に次を行います。

実行方法動作
対話（TTY）現在の git rev-parse HEAD を表示し、品質ゲート検証済みか・ステージング検証済みかをそれぞれ確認する（どちらも y 以外は中止）
非対話CONFIRM_QUALITY_GATE=1 と CONFIRM_STAGING_VERIFIED=1 の 両方 が必須。未設定または片方のみだと即終了する
SHA 固定（推奨）非対話では QUALITY_GATE_SHA=$(git rev-parse HEAD) を付ける運用を推奨。設定時は HEAD と一致しないと中止する（食い違い防止）

対話時でも両フラグを 1 にすればプロンプトをスキップできます。ステージング用の deploy-all-staging* にはこの確認はありません。

一括実行（推奨・品質ゲート確認あり）:

bash
# 対話: HEAD 表示後に品質ゲート・ステージング確認プロンプト
./bin/deploy-all.sh

# 非対話（CI ジョブや自動化）。QUALITY_GATE_SHA の指定を推奨
QUALITY_GATE_SHA=$(git rev-parse HEAD) \
  CONFIRM_QUALITY_GATE=1 CONFIRM_STAGING_VERIFIED=1 \
  ./bin/deploy-all.sh

./bin/build.sh（deploy-all 内で実行）は npm run build により Chart.js 等のフロントバンドル（hall-samai-graph.js / period-kishu-samai-ranking.js 等、.gitignore 対象）を生成してから core_src を _build/core_* にコピーします。バンドル未生成のまま PHP のみデプロイすると、グラフ系ショートコードは error_log のみで画面に JS が載りません。管理画面ビルドには gzip/Brotli 事前圧縮も含まれます。配信条件は 事前圧縮静的アセット を参照してください。

個別実行（品質ゲート確認なし）:

build.sh / deploy.sh / activate.sh / deploy-ftps-zip.sh を直接実行する経路には、上記の品質ゲート確認は入りません（確認バイパスになります）。本番反映の推奨経路は deploy-all* です。部分再実行や確認しながら進める場合のみ個別スクリプトを使い、その場合も事前に Run workflow または composer quality-check:full で HEAD を検証してください。

  1. ビルド（未実行の場合）

    bash
    ./bin/build.sh

  2. 本番へアップロード

    bash
    ./bin/deploy.sh

    またはバージョン（タイムスタンプ）を指定する場合:

    bash
    ./bin/deploy.sh 20250120_143022

    バージョンを省略した場合: 実行ログに表示されるバージョン名か、以下のコマンドで _build ディレクトリ一覧から最新を確認して、次の activate.sh に渡してください。

    bash
    ls -1 _build/core_* | sort | tail -n 1 | sed 's|.*/core_||'

  3. VERSION 切り替え＆キャッシュ削除

    bash
    ./bin/activate.sh 20250120_143022

    このスクリプトは SSH で本番サーバーに接続し、connector.php の VERSION 定数を指定したタイムスタンプに更新したうえで、PHP-DI コンパイル済みコンテナキャッシュを削除します。次回リクエスト時にキャッシュが新しい core_* から再生成されます。

    connector.php: 通常の deploy は core_* のみを差し替え、connector.php はサーバー上の本文を残したまま VERSION だけを書き換えます。WP-CLI コマンドは CliServiceProvider（core_* 内）で登録するため、connector に CLI 登録ブロックは不要です。本番の connector.php に削除済みクラス（例: KishuDisplayMigrationService の migrate-to-display）を参照する WP-CLI ブロックが残っていると、Web 表示は動いても wp コマンドが常に Fatal になります（Issue #3859）。その場合はリポジトリの connector.php と差分を確認し、本文を同期したあと ./bin/activate.sh <YYYYMMDD_HHMMSS> で VERSION を揃え直してください。

SSH が使えない場合の FTPS zip デプロイ ​

SSH 接続が利用できない場合の暫定ルートとして、FTPS で zip と一時デプロイレシーバーをアップロードし、HTTPS 経由でサーバー側展開・connector.php の VERSION 切り替え・PHP-DI キャッシュ削除を実行できます。

config/local.env に次を追加します。

bash
DEPLOY_FTPS_URL=ftp://your-ftp-host/public_html/slotkouryaku.com/wp-content/themes/cocoon-child-master/myCustom
DEPLOY_FTPS_USER=your-ftp-username
DEPLOY_FTPS_PASS=your-ftp-password
DEPLOY_FTPS_PUBLIC_URL=https://www.slotkouryaku.com/wp-content/themes/cocoon-child-master/myCustom

一括実行（品質ゲート確認は deploy-all.sh と同じ。非対話では両フラグ必須）:

bash
./bin/deploy-all-ftps-zip.sh
# 非対話例:
# CONFIRM_QUALITY_GATE=1 CONFIRM_STAGING_VERIFIED=1 ./bin/deploy-all-ftps-zip.sh

ビルド済みバージョンを指定して実行:

bash
./bin/deploy-ftps-zip.sh 20260713_120000

この方式では core_YYYYMMDD_HHMMSS.zip と、ランダム名・強トークン付きの一時 PHP レシーバーを FTPS で myCustom/ にアップロードします。zip には core_YYYYMMDD_HHMMSS に加えて、存在する場合は myTemplate/ と scripts/（.DS_Store / *.bak 除外）も含めます。レシーバーは POST リクエストでトークン検証後、zip をステージングディレクトリへ展開し、vendor/autoload.php の存在を確認してから core_YYYYMMDD_HHMMSS を配置します。myTemplate/ は上書きマージ、scripts/ は削除同期されます。connector.php は最後に更新され、成功時に zip とレシーバー自身を削除します。

注意:

  • SFTP ではなく FTPS を使用します。SFTP は SSH 接続に依存します。
  • 成功時に前回失敗で残った .deploy-stage-* / deploy-receiver-*.php / core_*.zip を掃除します。
  • 成功時に古い core_* を tiered 方針（最新5件常時保持・最大10件・2日超は6件目以降削除）で削除します。
  • scripts/ はリモート側を一度削除してから配置します。リモートで手動追加した一時ファイルも削除されます。
  • 一時レシーバーは Web 公開領域に置かれるため、実行後に自動削除されます。失敗時は myCustom/deploy-receiver-*.php が残っていないか確認し、残っていれば削除してください。
  • 通常の SSH デプロイが復旧したら、./bin/deploy-all.sh を優先してください。

GitHub Actions からのデプロイ（Deploy App） ​

ローカル SSH / FTPS に加え、Actions の Deploy App（.github/workflows/deploy-app.yml）から FTPS zip で本番反映できます。品質ゲート（CI Quality Gate）とは別ワークフローで、workflow_dispatch のみ起動します（develop push では自動デプロイしません）。

リポジトリ設定（初回のみ） ​

  1. Settings → Environments に staging / production を作成する（本番は Required reviewers を必須にする。自己申告の confirm チェックだけでは不正な ref の反映を防げないため）。
  2. 各 Environment に次の Secrets を設定する（値は環境ごとに異なる）:
Secret説明
DEPLOY_FTPS_URLFTPS 上の myCustom ディレクトリ URL
DEPLOY_FTPS_USERFTPS ユーザー名
DEPLOY_FTPS_PASSFTPS パスワード
DEPLOY_FTPS_PUBLIC_URL同ディレクトリの HTTPS 公開 URL
SITE_URLヘルスチェック用サイト URL（任意だが推奨）
  1. Repository secrets にビルド必須の法務埋め込み値を設定する（両 Environment 共通）:
Secret説明
LEGAL_OPERATOR_NAME法務文書シード用の公開事業者名
LEGAL_PUBLIC_CONTACT_EMAIL法務文書シード用の公開メール

任意で Environment / Repository variable DEPLOY_FTPS_ACTIVATE_TIMEOUT（未設定時 300 秒）。

注意（Actions 経路は FTPS のみ）: Environment に DEPLOY_SSH_KEY 等の SSH 用 Secrets を置かないでください。置いていると _deploy-ftps-zip-core.sh が SSH 展開に寄り、Actions ランナーから接続できないことがあります。ローカル SSH デプロイの正本は従来どおり ./bin/deploy-all.sh です。

実行手順 ​

  1. 反映するブランチ（通常は develop）で Actions → CI Quality Gate → Run workflow を実行し、対象 SHA がグリーンであることを確認する。
  2. 同一ビルドをステージングで検証する（ローカルまたは Deploy App の target=staging）。
  3. Actions → Deploy App → Run workflow で target=production を選び、confirm_quality_gate と confirm_staging_verified の両方にチェックを入れる。
  4. どちらか未チェックだとジョブは即失敗する（本番の誤デプロイ防止）。

キャッシュのみ削除したい場合 ​

VERSION の切り替えは不要でキャッシュだけ削除したい場合（DI 定義の変更を反映したい、不具合調査でキャッシュを外したいなど）は、clear-cache.sh を使用します。

bash
./bin/clear-cache.sh

ロールバック ​

問題が発生した場合は、activate.sh で旧バージョンを指定して切り替えます。

bash
./bin/activate.sh 20250115_091500  # 前回のバージョン

旧バージョンのディレクトリ（core_20250115_091500）がリモートに残っている必要があります。最新 2〜3 バージョンは削除せずに保持しておくことを推奨します。

関連ドキュメント ​