Vercel

Next.jsアプリのホスティングプラットフォームで、BenriWorksの各アプリと本サイトのデプロイ先として使用しています。

Vercelは、Next.jsアプリケーションのホスティングとデプロイを提供するプラットフォームです。BenriWorksでは、各アプリと本サイトBenriWorks Labのデプロイ先として使用しています。

「マージ＝公開」の運用

BenriWorksの公開フローは、GitHubへのPull Requestマージを公開操作とみなす形に統一しています。マージするとVercelが自動でProductionへデプロイし、ブランチをプッシュすればPreview環境が立ち上がります。サーバーの保守作業は一切なく、公開の失敗はビルドの失敗として現れるため、壊れた状態が本番に出にくい構成です。

個人で10を超えるアプリを運用できているのは、この「デプロイを考えなくてよい」性質によるところが大きいと感じています。デプロイ手順書が存在しないことは、数か月ぶりに触るアプリでも公開作業で迷わないことを意味します。

マルチプロジェクトとドメイン設計

BenriWorksではアプリごとにVercelプロジェクトを分け、benriwork.jpのサブドメイン（anzen-simulator.benriwork.jpなど）を割り当てる構成をとっています。プロジェクトを分けると、あるアプリのビルド失敗が他のアプリの公開を止めないこと、アプリごとに環境変数を隔離できることが利点です。

一方で、運用のなかで学んだ注意点もあります。

既定ドメインの扱い。 各プロジェクトには *.vercel.app の既定ドメインが付き、カスタムドメインを設定しても既定側は生き続けます。同じ内容が2つのURLで公開される状態になるため、vercel.json で既定ドメイン側にリダイレクトや X-Robots-Tag: noindex を設定し、検索エンジンから見た正規URLを一本化しています。
リダイレクトの種類。 ドメイン移転でリダイレクトを設定する場合、一時的な307ではなく恒久的な301/308を選ばないと、検索エンジンに評価が引き継がれません。ダッシュボードの既定値が307である点には注意が必要です。
配信設定とアプリ設定の整合。 vercel.json の trailingSlash や rewrites は、アプリ側のルーティング設定と揃っていないと、リダイレクトループや意図しない404の原因になります。本サイトをbenriwork.jp/blog配下へ統合した際は、rewriteによるプロキシ配信と basePath の組み合わせで実現しました。