Bash を使用してブランチ固有の Netlify 構成を自動化する – ステップバイステップ ガイド

バックエンド API とフロントエンド デプロイメントのために、ステージングと本番環境などの複数の環境でプロジェクトに取り組んでいる場合、リポジトリ内の各ブランチに正しい構成とコマンドがあることを確認する必要があります。

これは、複数の開発者がコードベースで積極的に作業したり、異なるブランチに変更を加えたり、複数のブランチ固有の設定を管理したりしている状況では、困難を伴う可能性があります。

ブランチにプッシュされたすべてのプル リクエストや変更と同様に、何がマージされるかどうかを決定する前に、変更、追加、または削除されたコードのすべての行を確認する必要があります。コードベース内の構成ファイルはこの例外から除外されないため、単純な変更が継続的インテグレーションのセットアップ全体に影響を与える可能性があるため、エラーが発生しやすくなります。

ステージング ブランチまたは本番ブランチに変更が加えられ、ビルドがトリガーされると、ブランチにアタッチされている正しいリソースが維持されるようにする必要があります。場合によっては、各クライアントごとに異なるリダイレクト ルール、カスタム ビルド コマンド、またはブランチごとのその他の設定を定義する必要がある場合があります。

この記事では、単純な bash スクリプトを使用して、複数のブランチのリダイレクトを含むブランチ固有の構成を自動的に管理する方法について説明します。また、Netlify 上のステージング ブランチと本番ブランチのコンテキスト固有のルールを安全にマージする方法も説明します。

説明する内容:

• プロジェクトの構造とシナリオ

• リダイレクト/リライトとは何ですか?

• Netlify がリダイレクトを処理する方法

  • _redirects ファイル構文の使用

  • netlify.toml 設定ファイル構文の使用

• 問題:異なるブランチの複数の netlify.toml ファイルの管理

• 設定ファイルを自動的に作成するスクリプトの記述方法

  • サンプル Netlify.toml ファイル

  • ステップ 1:スクリプト フォルダーを作成し、スクリプト ファイルを追加します

  • ステップ 2:package.json を変更してスクリプト コマンドを含めます

• クライアントを Netlify に導入する方法

  • Netlify へのプロジェクトの最初のデプロイメント

  • 後続のデプロイメント / ブランチ デプロイメントのセットアップ方法

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

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

• デプロイメントを検査する

• 結論

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

プロジェクトに 2 つの別々のサーバーがデプロイされている状況を考えてみましょう。1 つはステージング環境 (Render にデプロイ) へのリクエストを処理し、もう 1 つは本番環境 (Google Cloud Run にデプロイ) にリクエストを処理します。

また、Netlify には 2 つの個別のクライアント デプロイメントがあり、それぞれにそれぞれの API_BASE_URL があり、以下に示すように、それぞれのサーバーによってサービスが提供されます。

下の画像は sample-project です。 リポジトリ、api と client その中のフォルダー/ディレクトリ。これは、上で概説した各ブランチの構造の概要です。各ディレクトリには独自の package.json が含まれています。 ファイルは独立したコンポーネントとして扱われ、2 つの別々のサービスにデプロイできます。

各クライアントのフロントエンド展開では、/api/v1/ で始まるエンドポイントに対して行われるすべてのリクエスト サーバーにルーティングされます。他のルートはフロントエンド内に残り、クライアント内のページに誘導されます。したがって、これらのリクエストを処理する方法についてクライアントをガイドするための正しいルールを作成する必要があります。これらはリダイレクト ルールまたはリライトと呼ばれます。

リダイレクト/リライトとは何ですか?

リダイレクトまたはリライトは、特定の URL をインターネット上の新しい場所に自動的に移動させるために作成できるルールです (出典:WPengine)。これらは一般にURL 転送とも呼ばれます。 また、Web サイト全体、Web サイトのセクション、Web アプリケーション全体など、どこでも使用できます。

Web アプリケーションでは、リクエストの処理方法を決定するためにリダイレクトがよく使用されます。 Netlify や Vercel などのウェブ ホスティング プラットフォームでもこれらが使用され、開発者はウェブ アプリケーションがリクエストを処理する方法を決定するオプションが得られます。

Netlify がリダイレクトを処理する方法

Netlify では、リダイレクト ルールを指定する方法が 2 つあります。 _redirects を使用してこれを行うことができます。 ファイル構文または netlify.toml を使用する 構成ファイルの構文。同じ目標を達成しますが、netlify.toml は 構文により、より多くのオプションと機能が提供されます。

_redirects の使用 ファイル構文

リダイレクト構文の使用を選択した場合は、単純に _redirects を作成する必要があります。 ファイルをクライアント アプリのパブリック フォルダーに保存し、その中でリダイレクト ルールを指定します。それはとても簡単です。以下は、ファイル内のリダイレクト ルールの例です。

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

<オル>

/api/v1 に一致するすべてのリクエストを送信します 指定された API URL に送信し、成功ステータス コード 200 を返します。 /api/v1/ の後のアスタリスク (*) /api/v1/* に見られるように 元の URL の他の拡張子を指定された API URL に追加するように指示します。たとえば、/api/v1/users がある場合、 フロントエンドでルートを設定すると、リクエストは https://your-api-base-url.com/api/v1/users にリダイレクトされます。 。 :splat API URL にある は単なるプレースホルダーです。

他のすべてのデフォルト ルートは、index.html フォルダーを通じて提供されます。これは、他のページに移動し、「戻る」ボタンを使用して前のページにアクセスしようとしたときに、壊れたページが表示されないようにするために必要です。

netlify.toml の使用 設定ファイルの構文

netlify.toml 設定ファイルを使用すると、元のリクエスト ルート、必要な宛先、優先ステータス コード応答、ヘッダー ルール、署名、国の制限、役割などの一致を含むがこれらに限定されない、リダイレクト ルールを指定する際の柔軟性が大幅に高まります。

これはサンプル netlify.toml です。 ファイルのソースは Netlify のドキュメントです:

簡単なメモ: 特定のリクエストを API にリダイレクトするためにリダイレクト ファイルを使用することはまったく問題ありません。ただし、リダイレクトに API URL をプレーン テキストで追加することはセキュリティ リスクとみなされる可能性があります。 API_BASE_URL がプライベートであると想定されている場合は、ファイルを作成します。これは、パブリック フォルダ内のファイルはすべてその名の通り「パブリック」であり、誰でもアクセスできるためです。

アプリに含めたい直接の場所がパブリック URL である場合は、 _redirects を自由に利用してください。 ファイルの構文。ただし、プライベート URL を使用したい場合は、netlify.toml を利用します。 一般に、設定ファイルと環境変数を組み合わせた方が良い考えです。

問題:複数の netlify.toml の管理 異なるブランチのファイル

netlify.toml を使用する場合 ファイルを使用してビルド コマンドと環境固有の設定を定義し、変更を加えてリポジトリにプッシュしてプル リクエストを開くと、各 netlify.toml を手動で無視または編集する必要があります。 各支店で。これは最終的に非常にストレスがかかり、エラーが発生しやすくなります。

これに加えて、API URL が _redirects のどちらかにハードコーディングされることも避けたいと考えています。 または netlify.toml セキュリティ上の理由から、プロジェクトのコードベース内にファイルを含めないようにしてください。 Netlify UI 内で提供される環境変数を、本番環境およびステージング コンテキストに使用します。

上記の問題を回避するために、コードベースで小さなスクリプトを使用して、正しい netlify.toml を動的に生成します。 各ブランチのファイル。このアプローチにより競合が排除され、ブランチ間の切り替え時やプル リクエストの処理時に手動介入の必要がなくなります。

設定ファイルを自動的に作成するスクリプトの記述方法

サンプル Netlify.toml ファイル

以下はサンプル netlify.toml のスクリーンショットです。 各ビルドで達成しようとしているファイル。 api/v1/ に一致するすべてのリクエストが確認できます。 コードベース内の情報は API にルーティングされます。

API エンドポイント リクエストを別の構造にすることもできます (例:/api/your-endpoint)。 – それに応じてスクリプトを必ず調整してください。このサンプル プロジェクトでは、api/v1/your-endpoint を使用します。

ステップ 1:スクリプト フォルダーを作成し、スクリプト ファイルを追加する

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!"

スクリプトは次のことを行います:

<オル>

環境変数をチェックして、API_BASE_URL が有効であることを確認します。 が設定されています。これが設定されていない場合、ビルドが終了して失敗します。これは、実稼働環境で無効な URL を使用して、誤って正常なデプロイメントを作成しないようにするために行われました。

次に、netlify.toml のコンテンツを作成します。 上記のサンプルに示すようにファイルを作成します。 API エンドポイントが api/v1/your-endpoint とは異なる構造を使用している場合 、希望する構造に合わせてスクリプトを調整できます。

netlify.toml がすでに存在するかどうかを確認します。 ファイル。存在しない場合は、それを作成し、そこにコンテンツを書き込みます。存在する場合は、ビルド中に API_BASE_URL を使用して正しいコンテンツで更新されます。 環境変数に設定します。

ステップ 2:package.json を変更する スクリプト コマンドを含める

このスクリプトをビルド プロセスに統合するには、package.json にスクリプト コマンドを追加します。 実際のビルドを実行する前に、このスクリプトを呼び出すファイルを作成します。

configure-netlify を追加します 次のようなコマンド:"configure-netlify": "bash scripts/ configure-netlify.sh" package.json のスクリプト内 ファイル。

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

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

クライアントを Netlify に導入する方法

クライアントを Netlify にデプロイする場合、次の 3 つのオプションが与えられます。

<オル>

既存のプロジェクト (つまり、GitHub や GitLab などの git リポジトリ サービスに存在するプロジェクト) をインポートします。

テンプレートからインポートするか、

Netlify ドロップ (ドラッグ アンド ドロップ) インターフェイスを使用して、静的サイトを手動でデプロイします。

ビルド プロセス中にリポジトリ内の構成が期待どおりに機能するには、GitHub などの既存のプロジェクトからのインポートを必要とするオプションを使用する必要があります。ドラッグ アンド ドロップ インターフェイスの使用は機能しません。これを使用する必要がある場合は、_redirects を選択してください。 ファイル構文オプションを使用してリダイレクトを定義します。

Netlify へのプロジェクトの最初のデプロイメント

プロジェクトを初めてデプロイするときは、最初に 1 つのブランチのみをデプロイするオプションが与えられます。後続のデプロイメントでは、他のブランチなどの他のオプションのみを追加して指定できます。

プロジェクトをデプロイするには、次の手順を実行します。

<オル>

Netlify> netlify.com

にサインインします。

[新しいサイトを追加]> [既存のプロジェクトをインポート]> [GitHub を使用してデプロイ] をクリックします

「GitHub で Netlify を構成」をクリック> リポジトリを検索> 選択

プロジェクトの一意のサイト名を入力してください

デプロイ設定を構成します。ここでは、デプロイする優先ブランチを選択する必要があります。初期デプロイメントでは、main をデプロイします。 本番ブランチとして使用するブランチ。

• ブランチ:main/master

• ビルドコマンド:npm run build

• パブリッシュディレクトリ:dist (静的ファイルが存在するディレクトリを選択します。このサンプル プロジェクトでは、dist にエクスポートされます。 ディレクトリ。一部のツールは build にエクスポートします )

プロジェクトの環境変数を入力します。 API_BASE_URL を忘れずに入力してください サーバーから。これは、bash スクリプトによると必須の要件です。

「サイトをデプロイ」をクリックします。

プロジェクトは正しくデプロイされ、netlify.toml が表示されるはずです。 成功したデプロイメント ページの下部にあるデプロイメントの詳細を検査することにより、スクリプトによって生成された設定を確認します。

このファイルをローカル マシンにダウンロードすると、生成された構成を確認できます。サンプル netlify.toml と一致する必要があります。 上のファイル。生成されたサイト リンクを使用して、機能することをテストすることもできます。

その後の展開 / ブランチ展開の設定方法

ステップ 1:Netlify でブランチ コンテキストごとに環境変数を設定します — 本番、ステージングなど

プロジェクトが正常にデプロイされたら、ステージング ブランチのデプロイメントをセットアップできます。設定を編集するには、次のことを行う必要があります。

<オル>

サイトのリストに移動します

正常に展開されたサイトを選択してください

左側のメニューの「サイト構成」をクリックします

「環境変数」を選択し、「変数を追加」ボタンをクリックします。

変数を個別に追加するか、.env 全体をインポートするかを選択できます。 ファイル。どちらかのオプションを選択できます。下の画像では、「.env からインポート」を選択しています ファイル」。

main からデプロイされた実稼働サイトを確認します。 ブランチ (本番環境変数を含む) はすでにデプロイされているため、次のことを行う必要があります。

<オル>

本番ブランチのチェックを外します (最初にデプロイされたメイン ブランチを置き換えないようにします。異なるブランチの環境変数を混同しないように注意してください)

「ブランチ展開」を選択します。

.env ファイルの内容をコピーして、入力セクションに貼り付けます。

API_BASE_URL を忘れずに追加してください ステージング環境の環境変数

ブランチ デプロイを選択する場合、ここでインポートされた環境変数は、運用ブランチを除くすべてのブランチ デプロイに影響することに注意してください。カスタム ブランチを選択してコンテキストをさらにカスタマイズできますが、それはまったく異なるアプローチであり、netlify.toml をさらにカスタマイズする必要がある場合があります。 設定ファイルまたは bash スクリプト。

各環境変数を個別にインポートすることにした場合は、以下に示すような同様のオプションが表示されます。各ブランチに対して正しいコンテキストを選択していることを確認してください。

すべてのコンテキストに同じ値を使用しないでください。以下の図に示すように、「デプロイ コンテキストごとに異なる値」を選択します。 」を使用すると、それぞれの値を定義できます。この場合、ブランチ デプロイの値を定義します。最初に使用したプロダクション変数はすでに存在しているはずです。

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

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

すべての環境変数がさまざまなコンテキスト (この場合は実稼働とステージング) にインポートされたら、画面の左側のパネルにある「デプロイ」に移動します。次に、「デプロイをトリガー」ボタンをクリックし、キャッシュをクリアして、新しいデプロイを開始します。

展開を検査する

いずれかのデプロイメントを選択し、「デプロイ ログ」の構築ドロップダウンを選択することで、スクリプトが期待どおりに動作することを確認できます。コンテキストで定義されているように、コマンドの実行と、そのデプロイメントの出力と API URL が表示されます。

結論

このガイドの手順に従い、リポジトリ内の各ブランチでスクリプトと更新されたコマンドを使用すると、変更をプッシュすると Netlify が netlify.toml を自動的に生成または更新します。 各ブランチにファイルを作成します。これにより、ビルド時に各環境の正しい構成と環境変数が使用されるようになります。

スクリプトはすべてのブランチで同じままになります。これにより、スクリプトが正しい設定を安全かつ簡単に処理している間、他のコードの変更に集中できます。

変更を任意のブランチにプッシュして、実際の動作を確認します。

Twitter (@francisihej) または LinkedIn でお気軽にご連絡ください!

無料でコーディングを学びましょう。 freeCodeCamp のオープンソース カリキュラムは、40,000 人以上の人々が開発者としての職に就くのに役立ちました。始めましょう