マネージドへ公開

公開はサーバーを借りることではない

昔は、公開すると言えばサーバーを1台借りて、そこに自分でファイルを置いて、動かし続ける役目まで引き受けることでした。今の Next.js は、その手前で済ませられます。ビルドから起動までを代わりにやってくれるサービスがいくつもあり、まとめてマネージドと呼ばれます。管理してもらう、という意味です。

どのサービスを使っても、やることの並びはほぼ同じです。名前を覚えるより、この並びを覚えたほうが役に立ちます。

4つの手順

1. リポジトリを繋ぐ。 GitHub に置いたコードを、サービス側から見えるようにします。ファイルを手で送るのではなく、リポジトリを指定するだけです。

2. 環境変数を入れる。 API の URL や鍵のように、コードに書き残したくないものを、サービスの画面から登録します。ここが最初のつまずきどころです。手元では .env.local に書いてあって動いていたものが、本番には入っていないので落ちる、というのがいちばんよくある失敗です。

3. ビルドされる。 サービスが npm run build を勝手に走らせます。前のレッスンで scripts の名前を変えなかったのは、このためです。型のエラーがあればここで止まり、ログに理由が出ます。

4. URL がもらえる。 ビルドが通ると公開用の URL が渡されます。あとはブラウザで開くだけです。独自ドメインを後から繋ぐこともできます。

2回目からは push だけ

一度繋いでしまえば、次からは GitHub に push するだけで、また 1 から 4 が自動で走ります。手で公開作業をする回はもうありません。壊れたら1つ前の状態に戻せる仕組みも、たいていのサービスが持っています。

環境変数はコードに含まれないので、何が要るのかを忘れがちです。値は書かず名前だけを並べた .env.example をリポジトリに置いておくと、自分にも他の人にも親切です。

演習

公開の手順を4つ書き出し、本番に登録する環境変数の名前を .env.example にまとめます。

ヒント

.env.example
layout.tsx
page.tsx
プレビュー

できているか

  • 手順を4つ以上書いている
  • リポジトリを繋ぐ手順がある
  • 環境変数を入れる手順がある
  • ビルドが走ることを書いている
  • URL がもらえるところまで書いている
  • 環境変数の名前を2つ以上並べている
  • .env.example に公開 URL の名前を書いている
  • .env.example に API の名前を書いている