Bashスクリプトでブランチ固有のNetlify設定を自動化する方法 – ステップバイステップ完全ガイド

ステージング環境と本番環境など、複数の環境を持つプロジェクトでバックエンドAPIやフロントエンドのデプロイを行う場合、リポジトリ内の各ブランチに応じた正しい設定とコマンドを用意する必要があります。

しかし、複数の開発者が同じコードベースで作業し、それぞれ異なるブランチへ変更を加えている状況では、この管理は非常に煩雑になりがちです。

すべてのプルリクエストやブランチへの変更について、マージするかどうかを判断する前に、追加・修正・削除されたコードの行を確認する必要があります。設定ファイルも例外ではなく、わずかな変更がCI(継続的インテグレーション)全体に影響を及ぼす可能性があるため、ミスが起きやすい箇所です。

ステージングまたは本番ブランチに変更が加えられビルドが実行される際には、そのブランチに紐づく正しいリソースが維持されていることを確認したいものです。クライアントごとに異なるリダイレクトルールやカスタムビルドコマンド、その他の設定をブランチごとに定義しなければならないケースもあります。

本記事では、シンプルなBashスクリプトを使って、複数ブランチ向けのリダイレクトを含むブランチ固有の設定を自動的に管理する方法を解説します。さらに、Netlify上でステージング環境と本番環境それぞれに適したルールを安全にマージする方法も紹介します。

本記事で扱う内容

• プロジェクト構造と想定シナリオ
• リダイレクト/リライトとは何か?
• Netlifyがリダイレクトを処理する仕組み
  • _redirectsファイルの構文を使う方法
  • netlify.toml設定ファイルの構文を使う方法
• 課題：ブランチごとの複数netlify.tomlファイルの管理
• 設定ファイルを自動生成するスクリプトの書き方
  • サンプルのnetlify.tomlファイル
  • ステップ1:scriptsフォルダとスクリプトファイルを作成する
  • ステップ2:package.jsonにスクリプトコマンドを追加する
• クライアントをNetlifyにデプロイする方法
  • プロジェクトの初回デプロイ
  • 以降のデプロイ/ブランチデプロイの設定方法
    • ステップ1:本番・ステージングなど各ブランチ用の環境変数をNetlifyに設定する
    • ステップ2:新しいデプロイをトリガーする
• デプロイ結果の確認
• まとめ

プロジェクト構造と想定シナリオ

ここでは、1つのプロジェクトに対して2つのサーバーを別々にデプロイしている状況を考えてみましょう。1つはステージング環境向け(Renderにデプロイ)、もう1つは本番環境向け(Google Cloud Runにデプロイ)です。

また、Netlify上にも2つのクライアントデプロイがあり、それぞれ独自のAPI_BASE_URLを持ち、対応するサーバーから配信されています。以下の図のようなイメージです。

下の画像はsample-projectリポジトリの例で、その中にapiフォルダとclientフォルダが含まれています。これは前述の各ブランチにおける構成の概要です。各ディレクトリは独自のpackage.jsonファイルを持ち、独立したコンポーネントとして扱われ、2つの異なるサービスへデプロイできます。

各クライアントのフロントエンドデプロイでは、/api/v1/で始まるエンドポイントへのリクエストはすべてサーバーへルーティングされます。それ以外のルートはフロントエンド内にとどまり、クライアント内のページへ案内されます。つまり、これらのリクエストをどう処理するかをクライアントに指示するための正しいルールを記述する必要があります。これが「リダイレクトルール」または「リライト」と呼ばれるものです。

リダイレクト/リライトとは?

リダイレクト(リライト)とは、特定のURLをインターネット上の別の場所へ自動的に転送するために作成できるルールのことです(WPengineより)。一般にURL転送(URL forwarding)とも呼ばれ、Webサイト全体、サイトの一部、あるいはWebアプリケーション全体など、どこでも利用できます。

Webアプリケーションにおいて、リダイレクトはリクエストの処理方法を決めるためによく使われます。NetlifyやVercelといったホスティングプラットフォームもこれを採用しており、開発者は自らのWebアプリケーションがリクエストをどう処理するかを柔軟に制御できます。

Netlifyがリダイレクトを処理する仕組み

Netlifyでリダイレクトルールを指定する方法は2つあります。_redirectsファイルの構文を使うか、netlify.toml設定ファイルの構文を使うかです。どちらも同じ目的を達成できますが、netlify.tomlの方が多くのオプションと機能を利用できます。

_redirectsファイルの構文を使う方法

リダイレクトファイル方式を選ぶ場合は、クライアントアプリのpublicフォルダ内に_redirectsファイルを作成し、そこにリダイレクトルールを記述するだけです。非常にシンプルです。以下はファイル内のリダイレクトルールの例です。

上記のルールは次のように解釈できます。

1. /api/v1に一致するすべてのリクエストを指定したAPI URLへ送信し、200(成功)ステータスコードを返します。/api/v1/*のように/api/v1/の後に付いたアスタリスク(*)は、元のURLの残りのパスを指定したAPI URLの末尾に付加することを意味します。たとえば、フロントエンドに/api/v1/usersというルートがある場合、そのリクエストはhttps://your-api-base-url.com/api/v1/usersへリダイレクトされます。API URLに含まれる:splatはプレースホルダーです。
2. その他のデフォルトルートはindex.html経由で配信します。これは、ページ間を移動した後にブラウザの「戻る」ボタンで前のページへ戻ろうとしたときに、ページが壊れて表示されるのを防ぐために必要です。

netlify.toml設定ファイルの構文を使う方法

netlify.toml設定ファイルを使うと、リダイレクトルールの指定においてはるかに高い柔軟性が得られます。元のリクエストルートのマッチング、転送先、任意のステータスコードレスポンスだけでなく、ヘッダールール、署名、国別のアクセス制限、ロールなど、さまざまな設定が可能です。

以下はNetlify公式ドキュメントからのnetlify.tomlファイルのサンプルです。

補足：特定のリクエストをAPIへリダイレクトする目的であれば、_redirectsファイルを使っても問題ありません。ただし、API_BASE_URLが非公開であるべき場合、_redirectsファイルにAPIのURLを平文で記述するのはセキュリティリスクになり得ます。publicフォルダ内のファイルは文字通り「公開」されるものであり、誰でもアクセスできてしまうためです。

リダイレクト先が公開URLで構わないのであれば、自由に_redirectsファイル構文を活用してください。一方、非公開のURLを使用したい場合は、netlify.toml設定ファイルと環境変数を組み合わせて使うのが一般的におすすめの方法です。

課題：ブランチごとの複数netlify.tomlファイルの管理

netlify.tomlファイルでビルドコマンドや環境固有の設定を定義している状態で、変更をリポジトリへプッシュしてプルリクエストを出すと、各ブランチ内のnetlify.tomlを手動で除外または編集しなければなりません。これが繰り返されると、非常に負担が大きく、ミスも起きやすくなります。

さらに、セキュリティ上の理由から、プロジェクトのコードベース内にある_redirectsやnetlify.tomlにAPIのURLをハードコードするのは避けたいところです。本記事では、Netlify UIで提供されている環境変数を、本番およびステージングのコンテキストごとに利用します。

これらの問題を回避するため、コードベース内に小さなスクリプトを用意し、ブランチごとに正しいnetlify.tomlファイルを動的に生成します。このアプローチにより競合が解消され、ブランチ切り替え時やプルリクエスト対応時の手動作業も不要になります。

設定ファイルを自動作成するスクリプトの書き方

サンプルのnetlify.tomlファイル

以下は、各ビルド時に生成したいnetlify.tomlファイルのサンプルのスクリーンショットです。コードベース内でapi/v1/に一致するすべてのリクエストがAPIへルーティングされることが分かります。

APIエンドポイントの構造が異なる場合(例：/api/your-endpoint)でも問題ありません。その場合はスクリプトを適宜調整してください。このサンプルプロジェクトではapi/v1/your-endpointという構造を使用しています。

ステップ1:scriptsフォルダとスクリプトファイルを作成する

clientディレクトリ内にscripts/ディレクトリとconfigure-netlify.shスクリプトファイルを作成します。これはリポジトリ内の各ブランチで行う必要がありますが、内容はすべて同じで構いません。

configure-netlify.shスクリプトファイルを開き、以下の内容を貼り付けてください。

#!/bin/bash
# Ensure API_BASE_URL is set
if [ -z "$API_BASE_URL" ]; then
 echo "Error: API_BASE_URL environment variable is not set."
 exit 1 # Exit the script to stop the deployment
fi
echo "Using API endpoint: $API_BASE_URL"
# Define the desired Netlify configuration
NETLIFY_CONFIG="
[build]
 command = \"npm install && npm run build\"
 base = \"client\"
 publish = \"dist\"
[[redirects]]
 from = \"/api/v1/*\"
 to = \"$API_BASE_URL/:splat\"
 status = 200
 force = true
[[redirects]]
 from = \"/*\"
 to = \"/index.html\"
 status = 200
"
# Create or update the netlify.toml file
if [ ! -f "netlify.toml" ]; then
 echo "Creating netlify.toml file..."
else
 echo "Updating existing netlify.toml file..."
fi
echo "$NETLIFY_CONFIG" > netlify.toml
# Confirm successful configuration
echo "netlify.toml file has been configured successfully!"

このスクリプトは以下の処理を行います。

1. 環境変数をチェックし、API_BASE_URLが設定されていることを確認します。未設定の場合はビルドを終了させて失敗させます。これは、無効なURLを持ったまま本番環境でデプロイが成功してしまうミスを防ぐためです。
2. 上記サンプルのようにnetlify.tomlファイルの内容を生成します。APIエンドポイントの構造がapi/v1/your-endpointと異なる場合は、スクリプトを希望する構造に合わせて調整できます。
3. netlify.tomlファイルが既に存在するかどうかを確認します。存在しない場合は新規作成して内容を書き込みます。存在する場合は、ビルド時に環境変数に設定されたAPI_BASE_URLを使って正しい内容へ更新します。

ステップ2:package.jsonにスクリプトコマンドを追加する

このスクリプトをビルドプロセスに組み込むため、実際のビルドを実行する前にこのスクリプトを呼び出すコマンドをpackage.jsonファイルに追加します。

package.jsonのscriptsセクションに、"configure-netlify": "bash scripts/configure-netlify.sh"というコマンドを追加してください。

そして、ビルドコマンドを更新して、実際のビルド前にスクリプトが実行されるようにします:"build": "npm run configure-netlify && vite build"。

変更を保存し、リモートリポジトリへプッシュするのを忘れないでください。

クライアントをNetlifyにデプロイする方法

Netlifyにクライアントをデプロイする際には、3つの選択肢があります。

1. 既存プロジェクトをインポートする(GitHubやGitLabなどのgitリポジトリサービス上にあるプロジェクト)
2. テンプレートからインポートする
3. Netlify Drop(ドラッグ&ドロップ)インターフェースを使って静的サイトを手動デプロイする

リポジトリ内の設定がビルドプロセス中に期待通りに機能するためには、GitHubなどの既存プロジェクトをインポートする方法を選ぶ必要があります。ドラッグ&ドロップ方式では動作しません。どうしてもこの方式を使いたい場合は、代わりに_redirectsファイル構文でリダイレクトを定義してください。

プロジェクトの初回デプロイ

初めてプロジェクトをデプロイするときは、最初は1つのブランチのみをデプロイする形になります。他のブランチなどのオプションは、以降のデプロイで追加・指定できます。

以下の手順でプロジェクトをデプロイしましょう。

1. Netlify(netlify.com)にサインインします
2. 「Add new site」→「Import an existing project」→「Deploy with GitHub」をクリックします
3. 「Configure Netlify on GitHub」→ リポジトリを検索 → 選択します
4. プロジェクトの一意なサイト名を入力します
5. デプロイ設定を行います。ここでデプロイ対象のブランチを選択します。初回デプロイでは、本番ブランチとして使用するmainブランチをデプロイします
   • Branch: main/master
   • Build command: npm run build
   • Publish directory: dist(静的ファイルが出力されるディレクトリを選択します。このサンプルプロジェクトではdistディレクトリに出力されます。ツールによってはbuildに出力されるものもあります)
6. プロジェクトの環境変数を入力します。サーバーのAPI_BASE_URLを入力するのを忘れないでください。Bashスクリプトにとって必須の項目です。
7. 「Deploy site」をクリックします

プロジェクトが正常にデプロイされれば、デプロイ成功ページの下部にあるデプロイ詳細を確認することで、スクリプトによって生成されたnetlify.toml設定を見ることができます。

このファイルをローカルマシンにダウンロードして、生成された設定を確認できます。上記のサンプルnetlify.tomlファイルと一致しているはずです。発行されたサイトのリンクを使って動作テストも可能です。

以降のデプロイ/ブランチデプロイの設定方法

ステップ1:本番・ステージングなど各ブランチコンテキスト用の環境変数をNetlifyに設定する

プロジェクトのデプロイが成功したら、ステージングブランチ用のデプロイをセットアップできます。設定を編集するには、以下の手順に従います。

1. サイト一覧ページへ移動します
2. デプロイ済みのサイトを選択します
3. 左メニューの「Site configuration」をクリックします
4. 「Environment variables」を選択 → 「Add a variable」ボタンをクリックします

変数を個別に追加するか、.envファイル全体をインポートするかを選択できます。どちらでも構いません。下の画像では「Import from a .env file」を選択しています。

mainブランチからデプロイされた本番サイト(本番用の環境変数付き)は既に存在するため、以下の操作を行います。

1. 本番ブランチのチェックを外します(最初にデプロイしたmainブランチが上書きされないようにするため。ブランチごとの環境変数を混同しないよう注意してください)
2. 「Branch deploys」を選択します
3. .envファイルの内容をコピーして入力欄に貼り付けます
4. ステージング環境用のAPI_BASE_URL環境変数を追加するのを忘れずに

「Branch deploys」を選択した場合、ここでインポートした環境変数は本番ブランチ以外のすべてのブランチデプロイに適用される点に注意してください。カスタムブランチを選択すればコンテキストをさらに細かくカスタマイズできますが、それはまったく別のアプローチであり、netlify.toml設定ファイルやBashスクリプトのさらなるカスタマイズが必要になる場合があります。

環境変数を1つずつ個別にインポートする場合は、以下のように似たような選択肢が表示されます。各ブランチに対して正しいコンテキストを選択するようにしてください。

すべてのコンテキストで同じ値を使ってはいけません。下の画像のように、「different value for each deploy context(デプロイコンテキストごとに異なる値)」を選択すると、それぞれの値を定義できます。ここではブランチデプロイ用の値を定義します。最初に使用した本番用の変数は既に存在しているはずです。

すべての変数をインポートしたら、各変数の右側にあるドロップダウンを選択して値を確認し、正しくインポートされていることをチェックできます。

ステップ2:新しいデプロイをトリガーする

本番とステージングという異なるコンテキスト用の環境変数をすべてインポートしたら、画面左パネルの「Deploys」へ移動します。「Trigger deploy」ボタンを押し、キャッシュをクリアして、新しいデプロイを開始しましょう。

デプロイ結果の確認

任意のデプロイを選択し、「Deploy log」内のビルド部分のドロップダウンを開くことで、スクリプトが期待通りに動作しているか確認できます。コマンドの実行内容や出力、そしてそのコンテキストに応じて定義されたAPI URLが表示されます。

まとめ

このガイドの手順に従い、リポジトリ内の各ブランチに同じスクリプトと更新済みコマンドを配置しておけば、変更をプッシュするたびにNetlifyが自動的に各ブランチのnetlify.tomlファイルを生成・更新します。これにより、ビルド時に各環境に応じた正しい設定と環境変数が確実に使用されます。

スクリプト自体は全ブランチで共通です。これにより、設定の心配をすることなく、他のコード変更に集中できます。スクリプトが正しい設定を安全かつ簡単に処理してくれるからです。

ぜひ任意のブランチへ変更をプッシュして、この仕組みが実際に動く様子を確認してみてください。

筆者とはTwitter(@francisihej)やLinkedInでもつながれます!

無料でプログラミングを学ぼう。freeCodeCampのオープンソースカリキュラムは、これまで4万人以上の人々が開発者として就職するのに役立ってきました。今すぐ始めましょう。