自分のサーバーへデプロイするということは、エージェントに、自分でお金を払っているサーバー——他のものがすでに動いているかもしれないマシン——へのSSHに準じたアクセス権を渡すということです。これは無料のサブドメインへの公開とは信頼レベルが異なり、設定もそれを反映しています——数個のフィールドを一度だけ入力すれば、以降のすべてのビルドはボタン1つになります。ここでは、実際にデプロイ先を設定する前後に人々が尋ねる質問をまとめます。
デプロイ先を作るには何が必要？
設定 → デプロイの5項目です。
- 後から見て分かる名前——「prod-vps」「client-hostgator」など、夜11時にドロップダウンを見ても分かるもの
- ホストとポート
- SFTP認証情報
- ウェブルートのパス
APIトークンも不要、サーバーへのCLIインストールも不要、cronジョブの管理も不要です。ホストがSFTPアクセスを提供していれば——ほとんどの共有ホスティング、VPS、管理型WordPressホスティングが該当します——2分ほどで完了します。
パスワードとキー、どちらを使うべき？
ホストが対応していればキーを使ってください。パスワードでも問題なく動作しますし、あなたのアカウントに紐づけて保存していますが、キーの方が漏れる秘密情報が1つ少なくなります——後で何か問題が起きたときに「キーを1つ失効させる」だけで済むか、「たまたま使い回されていたパスワードを至るところでリセットする」羽目になるかの違いです。安価な共有ホスティングのSFTP設定にはパスワード認証しか用意されていないことも多く、それでも問題ありません。ただし、そのパスワードを他の場所で使い回さないようにしてください。
正しいウェブルートのパスはどう見つける？
これは初回に間違えやすい項目です。なぜなら間違った答えでも一見もっともらしく見えるからです。あなたのホームディレクトリでもなければ、 /var/www でもありません — ウェブサーバーが配信するよう設定されている、まさにそのフォルダです。
| サーバー | 一般的なウェブルート |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html — あるいは誰も覚えていない理由で3年前に前任の開発者が名付けたパスでもありません |
確信が持てない場合は、使い捨ての test.txt を、正しいと思うフォルダに任意のSFTPクライアントで置いてみて、それが yoursite.com/test.txtで読み込まれるか確認してください。ここを間違えても、デプロイは成功したと報告されます — エージェントは律儀に間違ったフォルダへファイルを書き込み、あなたは変化していない本番サイトを見つめながら、なぜだろうと悩むことになります。
1つのデプロイ先で複数のドメインをカバーできる？
できます。そしてこれは、最初のサイトを越えたところで本当に時間を節約してくれる部分です。デプロイ先とは1台のサーバーと1組の認証情報のことで、単一のドメインに紐づいているわけではありません。ドメイン管理で、各ドメインを個別のウェブルートオーバーライド付きでデプロイ先に紐付けます。Nginxのサーバーブロックで1台のVPS上に3つのサイトを運用している場合は？
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
デプロイ先1つ、紐付け3つです。SSHパスワードを3回入力し直す必要もなければ、キーをローテーションした日に1つだけ更新し忘れてズレていく、ほぼ同一のデプロイ先を3つ維持する必要もありません。3つのドメインのどれかでデプロイをクリックすれば、どのサーバーのどのフォルダかはすでに分かっています——デプロイ時に選び直す必要はありません。
接続時にエージェントは実際に何をしている？
まず周囲を確認します——読み取り専用で、まだ何も書き込みません。この調査では次を確認しています。
- 空のフォルダかどうか
- 同じビルドの以前のバージョンがあるかどうか
- 古いWordPressのインストールがあるかどうか
- ホストがデフォルトで置いた「近日公開」のプレースホルダーがあるかどうか
それによって戦略が決まります。空のウェブルートには単純なアップロードが行われます。すでに何か入っているウェブルートはより慎重に扱われます。実際の環境では、消えてはいけないものがサイトと同居しているケースが多いからです。
- A
.well-knownSSL検証用の - の
uploads誰もgitに入れていないディレクトリ - A
wp-config.php誰も触れてほしくない
ここでの作業は「消して置き換える」というより「何が変わったかを把握して整合を取る」に近いものです。
そして、1バイトも上書きされる前に、既存のウェブルートはあなた自身のホスト上でバージョンとしてキャプチャされます。データベースのレコードでも、こちらで計算して正しいことを願うだけの差分でもなく、実際にそこにあったもののスナップショットです。これは、どのターゲットへの最初のデプロイでも最も重要になります。なぜなら、そのデプロイは常に何かの上に着地するからです、たとえその何かが「何もないもの」であっても。空のフォルダなら、空のスナップショット。誰も作った記憶がない5年前の静的サイトも、触れられる前に無料で正確に保存されます。その最初のデプロイは、あなたが最も確信を持てないデプロイでもあるので、これが最も重要になる場面でもあります。
アップロードされるのはソースコード？それともビルド済みのサイト？
常にビルド済みのサイトです。静的サイトの場合、それは生成されたページ。フレームワークビルド — Next.js、Vite、そのサイトの種類が求めるもの — の場合はコンパイル済みの出力、つまり dist または build フォルダであり、ソースツリーではありません。これは正しい判断だと思っています。たとえそれが、SSHで入って npm run dev をサーバー上のものに対して実行できないことを意味するとしても。ソースをアップロードするということは、HTMLを配信するだけのために、本番ウェブルートにNodeランタイムとビルドツールチェーンが必要になるということです — ビルドパイプラインを実行することなど想定されていなかった共有ホスティングのマシンを、そういうものに変えてしまいます。そして、デプロイのたびに「サーバーに npm installを完了できるだけのメモリがあることを祈る」ことになります。コンパイル済みの出力だけを配置することで、ウェブルートは静的ファイルサーバーが期待するものそのままに保たれます。地味です。しかし何かがおかしくて、そのフォルダを見つめながら実際に何が配信されているのか把握しようとしている午前2時には、地味さこそが求めているものです。
デプロイが実際に成功したかどうか、どうやって分かりますか？
アップロード後、エージェントはライブURLにアクセスし、それが解決するかどうかを確認します — 500エラーでもなく、空白ページでもないこと。何が見つかったにせよ、また調査中に気づいてあなたの判断を仰ぎたいこと（「このウェブルートには私が触れなかった wp-content フォルダがあります、想定通りか確認してください」）も含めて、ビルドのチャットスレッドに投稿されます。それがこのプラットフォーム全体を通じたパターンです。静かな成功も、サポートチケットへの静かな失敗もありません。エージェントは、あなたがビルドを依頼したのと同じスレッドで、自分が見たものと決めたことを伝えます。
バージョン履歴には実際に何が含まれていますか？
デプロイのたびにバージョンが追加されます — 最初だけではありません。つまり履歴は、あなたのビルドを抽象的なタイムラインに並べたものではなく、そのウェブルートから実際に配信されてきたものの文字通りの順序です。あなたが現れる前にそこにあったものから始まります。バージョン1は常にそのプラットフォーム導入前の状態で、自動的にキャプチャされます。特に何も意識する必要はありません。
リバートは実際に何を復元しますか？
直前の本番バージョンを、正確に復元します — 古いビルドの再実行でも、近似でもありません。トラフィックを配信していた実際のファイルです。これは、私が他所で使ったことのあるほとんどの「ロールバック」機能よりも、意味のある強い保証です。それらは大抵「古いコミットから再デプロイする」ことを意味し、あなたのビルドプロセスが決定的であること、環境がその後変化していないことを暗黙に前提としています。ここでのリバートは既知の正常なスナップショットへの復元なので、プレッシャーの中で安心して使える理由もそこにあります — ロールバックが復元先と異なる挙動をする可能性を気にする必要がないのです。
そして実際にそれが必要になる瞬間は、決して落ち着いた瞬間ではありません。「新しいビルドがチェックアウトを壊し、今まさにトラフィックが流れている」という瞬間です。
ワンクリックで、直前のバージョンが復元され、完了です。これを後付けの機能ではなく第一級の機能として扱う理由は、Iterating without fearに書かれています — 必要になる前に一度読んでおく価値があります。履歴と復元コントロールはどちらも、ビルドカードとターゲット自身の履歴ビューにあります。
これは私のデータベースもバックアップしてくれますか？
いいえ、それは誤解を招くよりもはっきり言ったほうがいいでしょう。ホスト上のバージョン履歴がカバーするのは、このデプロイパイプラインがウェブルートに配置したものだけです。サイトにデータベースやユーザーアップロード、デプロイの外側で変化する何かがある場合、それは全く別の話です — リバートはそれには触れず、それをカバーするバックアップ戦略と勘違いしてはいけません。
