$ man context-wiki/deployments-vercel

デプロイとは、ローカルのコード変更をインターネット上に公開することだ。GitHub にプッシュする。Vercel がそれを検知する。サイトをビルドする。デプロイする。完了。初めて main にプッシュして、Vercel が 45 秒でサイトをビルドするのを見たとき、一番いい部分まで一気にスキップしたような気分だった。FTP アップロードは不要。手動のファイル転送も不要。コードをプッシュするだけで公開される。3 つのウェブサイト(shawnos.ai、thegtmos.ai、thecontentos.ai)すべてが 1 回のプッシュでデプロイされる。これは魔法ではない。現代のデプロイの仕組みだ。

パターン

すべてのブランチに独自のプレビュー URL がつく。フィーチャーブランチを GitHub にプッシュすると、Vercel が固有の URL を生成し、本番に反映する前に変更を確認できる。テストにとって非常に有用だ。プレビュー URL をコラボレーターと共有したり、スマホで確認したり、main にマージする前に変更が正しく見えるか検証したりできる。 ワークフロー：ブランチを作成し、変更を加え、ブランチをプッシュし、プレビュー URL を確認し、問題があれば修正し、問題なければ main にマージすれば、main が自動的に本番環境にデプロイされる。壊れたコードを本番にデプロイすることは絶対にない。プレビューの段階で気づくからだ。

パターン

秘密情報は Vercel 上に置く。コードの中ではない。API キー、データベース URL、MCP トークン。Vercel のダッシュボードで各プロジェクトに追加する。デプロイされたサイトは process.env を通じてアクセスする。リポジトリには決して現れず、Git にコミットされることもなく、ビルドログに表示されることもない。 ローカルでは、同じ変数を入れた .env ファイルを作成する。.env を .gitignore に追加してコミットされないようにする。Vercel には本番環境用の独自のコピーがある。この分離により、ローカル開発と本番環境で異なる値を使っても競合しない。

プロのコツ

デプロイの手順を覚えなくていいように /deploy スキルを作った。変更されたすべてのファイルをステージングする。diff からコミットメッセージを生成する。コミットする。GitHub にプッシュする。Vercel がビルドを開始するのを待つ。ビルドの進捗を監視する。3 つのサイトすべてがステータスコード 200 で公開されたことを確認する。結果を報告する。/deploy と入力すれば、あとはすべて自動で行われる。3 つのウェブサイト、1 回のプッシュ、1 分以内。 これはスキルパターンをインフラに適用したものだ。コマンドを手動で実行することもできる。でもなぜそうする? スキルの方が速く、一貫性があり、自分では見逃すエラーをキャッチしてくれる。デイリートラッカーへのデプロイ記録も残してくれる。

アンチパターン

デプロイが失敗する一般的な理由は 3 つだ。ビルドエラー：TypeScript のエラー、不足しているインポート、壊れた依存関係。ローカルでエラーを修正して再度プッシュする。環境変数の問題：ある変数がローカルには存在するが Vercel にはない。Vercel のダッシュボードを確認して不足している変数を追加する。依存関係の競合：ロックファイルが package.json と同期していない。node_modules を削除し、再インストールし、更新されたロックファイルをプッシュする。 /deploy スキルはビルド状態をチェックし、関連するエラーとともに失敗を報告する。しかしスキルをスキップして手動でプッシュした場合は、Vercel のダッシュボードでビルドログを確認する。エラーは常にログの中にある。推測する前にログを読むこと。