# デプロイ設定手順 — GitHub Actions → ConoHa(SSH)

**作成ブランチ**: `claude/content-verification-undx76`（main未マージ）
**目的**: 「Claude Code web/Cursor で実装 → GitHub に push → Actions が ConoHa へ SSH デプロイ」を、**秘密鍵をリポジトリにもサンドボックスにも置かず**に実現する。

---

## 全体像

```
実装 (Claude Code web / Cursor)
   │ git push
   ▼
GitHub (main)
   │ push トリガ
   ▼
GitHub Actions runner ── SSH/rsync ──▶ ConoHa (/var/www/...)
   （秘密鍵は GitHub Secrets。runner が実行時に読むだけ）
```

- **秘密鍵の置き場所 = GitHub Secrets のみ**。リポジトリ本体・このサンドボックスには一切置かない。
- **このサンドボックス/Claude Code web の役割は `git push` まで**。SSH 接続は Actions が担当（ここから直接サーバへ繋がない＝鍵をここに置かない）。
- ワークフロー本体は `.github/workflows/deploy.yml.proposed`（レビュー用に `.proposed`。有効化時に `deploy.yml` へリネーム）。

---

## 前提（先に決めること）

1. **`.github` をどのブランチの正にするか**
   現状 `main` には `.github` が無く、旧 `deploy.yml`（SFTP・故障）は `wip-version-badge-and-import-20260619` にのみ存在。
   → **main/wip のどちらを正に集約するか**を決めてから、本ワークフローを main に載せる。
2. 旧 `SamKirkland/FTP-Deploy-Action`（SFTP非対応で全赤字）は**廃止**し、本SSH方式に置換。

---

## 手順A: サーバ側（ConoHa・人間が実施）

> SSH鍵はこのサンドボックスでは生成しない。**自分のローカルマシン**で生成する。

1. デプロイ用鍵を生成（ローカル）:
   ```
   ssh-keygen -t ed25519 -C "github-actions-deploy" -f ./monaka_deploy_key
   ```
   → `monaka_deploy_key`(秘密鍵) と `monaka_deploy_key.pub`(公開鍵) ができる。
2. ConoHa に**非rootのデプロイ用ユーザー**を作成（例 `deploy`）。既存運用に合わせて可。
3. 公開鍵をサーバへ登録:
   ```
   ssh-copy-id -i ./monaka_deploy_key.pub deploy@<ConoHaのIP>
   # または authorized_keys に手動追記
   ```
4. デプロイ先ディレクトリの所有者を `deploy` ユーザーにし、書き込み可能にする
   （例 `/var/www/html/putage.maspis.com`）。
5. `deploy` ユーザーで `php` / `composer`（必要なら）/ `git` が使えること、
   `php artisan migrate` 実行に必要なDB権限があることを確認。
6. **rootでのデプロイは避ける**（旧ワークフローは root + パスワードだった。セキュリティ改善）。

## 手順B: GitHub Secrets（人間が実施）

リポジトリ → Settings → Secrets and variables → Actions → **New repository secret** で以下を登録:

| Secret 名 | 値の例 | 説明 |
|---|---|---|
| `SSH_PRIVATE_KEY` | `monaka_deploy_key` の中身（`-----BEGIN ...` 全文） | デプロイ用秘密鍵 |
| `SSH_HOST` | `133.130.90.66` 等 | ConoHaのIP/ホスト |
| `SSH_USER` | `deploy` | 非rootデプロイユーザー |
| `SSH_PORT` | `22` | SSHポート |
| `DEPLOY_PATH` | `/var/www/html/putage.maspis.com` | 配置先 |

> IP・ユーザー・パスを**ワークフローに直書きしない**（旧 deploy.yml は IP と root を平文コミットしていた＝改善点）。

## 手順C: 有効化（人間が実施）

1. 本ブランチの `.github/workflows/deploy.yml.proposed` を **`.github/workflows/deploy.yml`** にリネーム。
2. main へ取り込む（あなたの運用に従い、Cursor で main に反映 or PR マージ）。
3. main への push で自動デプロイ。初回は **`workflow_dispatch`（手動実行）** で動作確認推奨。

---

## ワークフローの動作（`deploy.yml.proposed`）

1. checkout → PHP/Node セットアップ
2. `composer install --no-dev` / `npm ci && npm run build`（runner上でビルド）
3. `webfactory/ssh-agent` で `SSH_PRIVATE_KEY` を ssh-agent に読み込み（**ディスクに書かない**）
4. `ssh-keyscan` で known_hosts 追加
5. **rsync over SSH** で配置（`--delete` で不要ファイル削除、ただし下記は除外して**サーバ側を保持**）
   - 除外: `.env` / `storage/app/public` / `storage/logs` / `storage/framework/{cache,sessions,views}` / `public/storage` / `.git` / `node_modules` / `tests` / `docs` / `_deliveries` / `*.tar.gz`
6. SSH で配置先に入り **`migrate --force` → `storage:link` → `config:clear` → `view:clear` → `view:cache`**
   - `route:cache` は使わない（`RouteServiceProvider` にクロージャ＝LINE webhookルートがありキャッシュ不可）

---

## 注意・リスク

- **`rsync --delete`**: 配置先のリポジトリ管理外ファイルを消し得る。`.env`・`storage`・`public/storage` は除外済みだが、**サーバ側に手置きした重要ファイルがあれば除外に追加**すること。初回は `--delete` を外して差分を確認するのも可。
- **`migrate --force` の自動実行**: 破壊的マイグレーションが混ざると本番に即反映される。**前回監査のDB項目（partners欠落・FK型）解消前は、migrateを手動運用にする選択肢**もある（ワークフローから外し、デプロイ後に人手で実行）。
- **`.user.ini` / `public/.user.ini`**（PHP上限設定）はリポジトリ管理下なら配置される。サーバ固有設定は除外検討。
- 本番DBのバックアップ（`putage:db-snapshot`）が cron で回っていることを前提に、初回デプロイ前に手動スナップショット推奨。

---

## まとめ（あなたの制約との対応）

| 制約 | 本手順での対応 |
|---|---|
| GitHubで全部実装したい | ✅ ワークフロー＋Secretsで完結。デプロイはActionsが実行 |
| サンドボックスに鍵を入れない | ✅ 鍵はGitHub Secretsのみ。サンドボックスは`git push`まで |
| GitHubにサーバAPI未設定 | ✅ 必要なのはSSH鍵をSecretsに入れるだけ（手順A/B） |
| mainマージはまだしない | ✅ 本ファイルは`.proposed`＋`docs`。有効化はあなたの判断で |