Vercelについて
Vercelは、静的ウェブサイト（純粋な静的ページであり、インターフェースデータのやり取りがない）およびダイナミックウェブサイトのアプリケーションのデプロイ、プレビュー、および公開をサポートするクラウドサービスプラットフォームです。GitHub Pagesを使用したことがある場合は、それほど不慣れではないかもしれませんが、VercelをGitHubと統合することで、GitHubのプロジェクトでコードをプッシュし、PRマージして自動的にデプロイすることも可能で、そしてサーバー問題を心配する必要はありません。
これはVercelの実現可能性調査プランというよりも、Vercelの使用方法普及と言えます。なぜなら、Vercel自体にCI CDが組み込まれているため、プロジェクトをVercelに関連付けるだけでコマンドを使って簡単にデプロイすることができます。次に、Vercelの利点やデプロイの方法、能力の制約および今後検討すべきポイントについて説明します。
Vercelの利点（何が得られるか）
Vercelを使用することで私たちは何を得ることができるのでしょうか？Vercelの能力上の利点については、自分の使用経験に基づいて簡単なリストアップを行います：
- 個人向けのバージョンは永久に無料で、毎月100Gの帯域幅（他のユーザーがあなたのプロジェクトにアクセスする際に消費されるデータ量）があります。個人プロジェクトをデプロイするには十分ですが、チームモードでは料金が発生します。したがって、協力するためには有料です。
- 組み込みのCI/CDは、ブラックボックスと考えることができて、プロジェクトをVercelにインポートし、コマンド一つで自動的にデプロイすることができます。
- 組み込まれたビルドプロセスにより、コードのプッシュやPRの自動ビルドトリガーなどをサポートし、異なるブランチごとに固有のアドレスを提供してテストしやすいです。
- ローカル環境、テスト環境、本番環境の3種類のデプロイをサポートしており、コマンドだけが異なるため非常に低い学習コストです。
- 豊富な統合機能では、プロジェクトデプロイ時の自動監視やエンドツーエンドの自動化テストなどが可能です。これらはすべてVercel自体の機能ではありませんが、統合エントリーポイントを提供してくれるため、これらは自動デプロイ中またはその後も実行されます。例えば、本番ビルド後にパフォーマンスメトリクス出力や自動化テスト、プロジェクトモニタリングなどのことができます。
デプロイ方法
Vercelにプロジェクトをインポートすると、Vercelは、プロジェクトで使用されるフレームワークの最適なビルド設定とデプロイ設定を自動的に検出して設定します。これが、プロジェクトをインポートするだけで直接ビルドできる理由の一部です。まず、Vercelプラットフォームにプロジェクトをインポートする2つの方法について説明します。
GitHubデプロイ
ダッシュボードで「Add New」ボタンをクリックし、「Project」を選択します。そうすると、プロジェクトのインポート画面に移動します。GitHubアカウントを選択（以前にバインドしていない場合でもここでGitHubアカウントをバインドすることができます）し、次にインポートボタンをクリックします。その後、プロジェクトの設定ページに移動します。
例えば、ここでは私が事前にVercelの公式NextテンプレートプロジェクトをGitHubアカウントにクローンし、このNextプロジェクトをインポートしてみました。Vercelは自動的にこのプロジェクトがNext.jsフレームワークを使用していることを認識し、ビルドコマンドもnpm run buildと自動的に認識します。もちろん、プロジェクトのフレームワークが正しく認識されない場合は、自身のプロジェクトで後続でpnpmなど他のコマンドを使用する可能性がありますので、これらの設定は実際の状況に応じて変更することができます。ここではデフォルト値を使用します。
下記の「Deploy」ボタンを直接クリックしてデプロイし、ビルド自動的にが完了した後、Vercelから割り当てられた一意なプレビューアドレスが表示されます。
実際の開発では、私たちは必ずGitHub上のリポジトリもクロンするので、その後、プロジェクトのコードを変更し、リポジトリにプッシュするだけで、GitHubはコードの変更を検知し、Vercelが自動的に再デプロイします。
「GitHubプロジェクトをコピーしてメインブランチと開発ブランチがあって、Vercelはどうデプロイ先の環境を判断するのか」と思うかもしれませんが、実際にVercelは事前設定も行っており、コードの変更が「main」または「master」ブランチで発生した場合、本番環境へのビルドとデプロイを自動的に行います。それ以外のブランチでは、Vercelはプレビュー（テスト）環境を更新します。
GitHubのメインブランチに関しては、GitHubで設定することができますが、これについてVercelは感知する必要はありません。メインブランチが変更された場合には適切なデプロイ処理を行ってくれますからね。また、リモートリポジトリのコード変更には2つの方法があります。1つ目はローカルで直接コードをプッシュすることです。2つ目はPRを提出し、ターゲットブランチにマージして変更をトリガーすることです。
GitHubを統合している場合、PRをマージする前に、デプロイされたブランチのプレビューアドレスを直接GitHub PRで確認することさえできます。Vercelがデプロイした効果も直接確認できます。
以下の図は、私がメインブランチ main から開発ブランチ main-echo作成した例です。
次に、 main ブランチに対して PR を作成しました。PR のマージページでは、GitHub が main-echo ブランチのデプロイプレビューのアドレスを直接提供しています。その後、PR をマージします。main ブランチのコードが変更されたため、Vercel は自動的に main ブランチをビルドしてデプロイします。この方法では、各ブランチの効果が予想通りかどうかを確認することができます。
R をマージした後は、vercelは、本番環境を更新し、しかもコミット履歴をGitHubと同期させました。
ローカルデプロイ
プロジェクトがGitHub上にない場合でも、GitHubへのアップロードや初期化などの手順が不要であれば便利です。そのためには、ローカルでVercelを初期化し、プロジェクトを直接Vercelに関連付けて異なる環境へのデプロイ効果を実現することができます。
Vercelをローカルにインストールする必要があります。グローバルインストールすることをおすすめします：
npm install -g vercel
次に以下のコマンドを実行して、vercelアカウントにログインしてください：
vercel login
その後、プロジェクトのルートパスに移動します。
vercel
その後、いくつかの基本設定が必要です。たとえば、デプロイするプロジェクトディレクトリ、ビルドコマンド、および出力ディレクトリを選択する必要があります。直接Enterキーを押すとデフォルトの設定で実行されます。これらの設定が完了すると、プロジェクトはデプロイされます。ターミナルでのデプロイ完了後に表示されるURLで直接確認できます。また、Vercelのバックエンドに戻り、関連付けたプロジェクトを見つけて同様にプレビューアドレスを見つけることもできます。
GitHubのデプロイとローカル環境でのデプロイにはいくつかの違いがあります。GitHubを統合した場合、VercelはGitHubコードリポジトリのブランチ変更に応じて自動的な環境マッチングを行います。
- 本番環境：例えばGitHubメインブランチにコード変更があった場合（pushなど）または、PRがメインブランチにマージされると、本番環境の再デプロイが発生します。メインブランチのデフォルトは「main」または「master」ですが、GitHubでカスタムすることもできます。
- プレビュー環境：メインブランチ以外の他のブランチにコード変更がある場合、Vercelはそのブランチ専用のプレビューアドレスを自動的に構築します。
ローカルデプロイメントもコマンドを使用して直接行うことができますが、GitHubを統合する場合はGitHubワークフローを利用することをお勧めします。これにより、構築プロセスがより規範化されます。
したがって、構築コマンドは主にローカルデプロイメント向けです。なぜならば、プロジェクトはGitHubと統合されていないため、Vercelではコード変更を感知する手段がありません。そのため開発者は手動で異なる環境へのデプロイ更新を達成するためにコマンドを使用しなければなりません。次に異なる環境間の違いと対応するコマンドを紹介します。
コマンドと環境の構築について
Vercelは、開発環境、プレビュー環境（テスト環境）、および本番環境の3つの概念に分かれています。Vercelチーム版では、プレビュー環境で直接コメントをすることができます（そしてコメントはSlackにも統合されるため、現在のエコシステムに非常に適しています）。例えば、UIデザイナーが特定のページの再現度が十分でないと感じた場合、プレビュー環境でコメントをすることができます。したがって、異なる環境は本質的な違いと役割を持っています。
以下の3つのコマンドを使用して異なる環境をそれぞれ構築することができます。非常にシンプルです。一言で言えば、以下のようなものです：
-
vercel dev：このコマンドは、ローカル開発環境を起動するために使用されます。これにより、Vercelのクラウド環境をシミュレートし、開発とテストをローカルで行うことができます。このコマンドを使用すると、プレビューまたは本番環境にデプロイせずに変更内容の効果をリアルタイムで確認することができます。
-
vercel：このコマンドは、プロジェクトをVercelのプレビュー環境にデプロイするために使用されます。プレビュー環境はテストや共有目的で一時的な環境で、変更が本番環境で表示される方法を見ることができます。このコマンドはチームでの協力シナリオに非常に適しており、変更内容を共有し、フィードバックを受け取り、本番環境にプッシュする前にさらなる調整を行うために使用することができます。 -
vercel --prod：このコマンドはアプリケーションを本番環境にデプロイします。本番環境は通常、アプリケーションの公式リリースバージョンを表し、展開されたコンテンツは一般の人々から見えるようになります。このコマンドはプロジェクトを最終的にオンライン上へデプロイする手順です。
踏み込んだ問題と Vercel プラットフォーム設定
Vercel プラットフォーム自体は非常にシンプルです。プロジェクトのインポートやコードの推送など数行のコマンドでほとんどの要件を満たすことができますが、実際的な困難点は個人のプロジェクトを Vercel へインポートし、成功裏にデプロイすることだと思います。例えば、あなたがVercelの公式フレームワークテンプレートを使用しているとします。これらのテンプレートは非常に純粋でシンプルなため、変更する必要がなく成功することが保証されています。しかし、もし開発歴が長く様々なカスタマイズされたプロジェクトを持っている場合は、順調ではないかもしれません。以下では私がVercelにプロジェクトをデプロイする際に起きた問題について説明します。
- Vercelのデプロイではファイル名の大文字小文字の参照に厳しいです。例えば、自分のプロジェクトでファイルを参照する際に一部は小文字でありながら特定のアルファベットだけ大文字であったりする場合、Jenkinsではこれらは正常に動作しエラーも出ませんが、Vercelではエラーと見なされます。下記画像のように直接エラーと報告されます。
実際のファイル名は checkbox ですが Checkbox と書かれております。そのためこのようなエラーが発生した場合はビルドエラーファイルを見てリソースが存在するか確認してください。または、リソースの命名が大文字と小文字を区別しているかどうかを確認してください。
- Vercelは将来的にNode 18バージョンのみサポートする予定であり、Vercelプラットフォームではデフォルトで18バージョンが使用されます。一般的に、以下のエラーが発生した場合は、Nodeのバージョンが高すぎることを意味します。例えば、現在のプロジェクトで16バージョンを使用し、Vercelデプロイメントで18バージョンを使用するとエラーが発生します。
以前は自分のローカル環境のNodeバージョンを下げる必要があると思っていましたが、後よく考えてみれば違いますね。Vercelのデプロイは、そのサービスを使用して行われて、ローカル環境とは関係ありません。やっはりプロジェクトの設定でノードのバージョン設定を見つけました。プロジェクトのノードバージョンに一致するバージョンに変更してからビルドすると、上記のエラーは発生しません。
しかし、このエラーを回避するために16に変更したとしても、Vercelは依然としてノードバージョンの警告を表示します。今年8月以降ではnode 14および16のバージョンのデプロイはサポートされなくなりますし、公式ブログでもこの問題が取り上げられています。
- 自分のプロジェクトの構成に基づいて、Vercelプラットフォームのプロジェクト設定を調整する必要があるかもしれません。例えば、ここではビルド関連の設定を確認できます。前にも述べたように、Vercelは自動的にフレームワークを識別してデフォルトの設定を初期化します。例えば、私たちのプロジェクトはumiとして正常に識別されましたが、実際の出力ディレクトリは異なる名前です。そのため、ここで修正する必要があります。
- Vercelプラットフォーム環境ではzipをサポートしていません。長い間プロジェクトをビルドする際にVercelがzipコマンドが見つからないエラーを報告していますが、私の依存パッケージにそのパッケージ名はありませんでした。念のため、私はプロジェクト内にzipパッケージを専門的にインストールしましたが、結果は変わりませんでした。その後、GPTに質問してみると、ビルドコマンド中にアーティファクトを圧縮するための一部のzipコマンドが見つかりました。この行動を削除した後、ビルドは正常に行われました。また、上記のようなエラーが表示された場合でも2つのエラーに気を取られず無視してください。例えば、exited with 1のようなエラーは、ビルドの失敗に関連する一般的なエラーです。これはインターフェース500が一般的なコードを提供するようなものであり、本当のエラーは必ず最初の文にあるため、このエラーを解決すればいいです。
能力境界
上記はVercelプラットフォームでのデプロイと注意点について説明しましたが、将来のプロジェクト開発を考慮して、私が気付いた能力境界についても紹介します。
ドメインのカスタマイズをサポートする
理論的には、Vercelはプロジェクトをデプロイした後、ユニークなアドレスを生成しますが、すべてのアドレスにはvercelの接尾辞が付いています。本番環境では、vercelの痕跡が明らかすぎるため、ドメインを購入している場合はプロジェクト設定でドメインをカスタマイズすることもできます。
デプロイURLの非公開化とプレビューアドレスのカスタマイズ（有料）
Vercelでは、プレビュー環境や本番環境をデプロイする際に一意なURLが自動的に生成されます。デフォルトではそのURLは公開アクセスできますが、デプロイ保護を使用してプライベートアドレスに設定することもできます。たとえば、テストアドレスへの外部からのアクセスを望まない場合です。
ここではいくつかのURLの構造を紹介します。
本番環境で生成されるアドレスは通常、プロジェクト名とスコープを組み合わせて以下のような構造になります：
<project-name>-<scope-slug>.vercel.app;
それ以外にも、プロジェクト名と一意のハッシュ値を組み合わせたアドレスもあります：
<project-name>-<unique-hash>-<scope-slug>.vercel.app
もちろん、時々プロジェクトを区別する必要があるので、Vercelはプロジェクトのブランチを組み込んだアドレスも提供しています：
<project-name>-git-<branch-name>-<scope-slug>.vercel.app
ブランチ以外にも、私たちがチーム版であると仮定すると、Vercelはユーザー名をプロジェクト名に追加したアドレスも提供します。これにより、このアドレスが誰のビルドであるかを区別しやすくなります。構造は次のようになります：
<project-name>-<author-name>-<scope-slug>.vercel.app
プロジェクトデプロイパネルでは、異なるタイプのアドレス形式を確認することができます。もちろん、これらのアドレスは最終的に完全に同じ表示効果です（ここでは個人版です）。
少しデプロイの保護について話しましょう。Vercelは、個々のデプロイにパスワード保護を追加するか、デプロイをプライベート化することができます。前者は事前に設定されたパスワードを入力してアクセスできるようになりますが、後者はすべてのデプロイアドレスを直接大規模にプライベート化することができます。アクセスするためにはパスワードまたはVercelの認証が必要です。例えば、企業版ではチーム外の人々がテストアドレスにアクセスしないようにしたい場合などです。
ただし、この機能を利用するにはエンタープライズ版またはPROバージョンが必要です。簡単に言えば、無料で使用することはできません。
nextプロジェクトとMonoreposリポジトリのデプロイをサポート
例えば、将来的にはプロジェクトのリポジトリをMonoreposに移行する必要があります。一つのプロジェクトの下には、個々のサブプロジェクトをそれぞれデプロイする必要があります。現在、VercelはMonoreposリポジトリのデプロイを非常にサポートしており、公式でMonoreposリポジトリの例も提供されています。簡単なため、皆さん自身で試してみることができます。また、Vercelはnextプロジェクトに対しても非常にフレンドリーなサポートを提供しております。
豊富な統合能力
VercelはGitHubとの統合だけでなく、パフォーマンステストやセキュリティチェック、監視機能、エンドツーエンドテストなどの一連の機能も提供しています。ただし現在私たちが取っている方法では異なるプラットフォーム（例えばSentry）に分散させており、自動化デプロイパイプライン内では一部です。
終わりに
以上がVercelプラットフォームについての紹介ですご質問があれば、どうぞお気軽にお申し出ください。また、この記事が皆様のお役に立てることを願っています。
創作チーム
作者：Echo
校閲：Lila、Yuki