シックブラウザ（html / javascript / css）クライアントのデプロイメント構成をどのように処理しますか？
質問
Html/javascript/cssの「シッククライアント」、特にクライアントに依存しないサーバーAPIに対して機能するクライアントの場合、デプロイメント環境の構成をどのように管理しますか？
環境ごとのリリースビルド（QA、STAGEなど）を使用してビルド時に構成を管理しますか、それとも一般リリースをビルドしてサーバー側の構成に依存しますか？あなたの経験で最もうまくいったことは何ですか？
バックグラウンド
私の会社には、いくつかの異なるシックブラウザクライアントがあります。すべてのクライアントはいくつかの共通の属性を共有しています。
- これらは、クライアント固有の懸念を認識していない一般的なAPIサーバーに対して動作します
- これらはデプロイ時に完全に静的であり、サーバー側の処理なしでApacheを介して配信されます。つまり、各環境には独自のリリースビルド（QA、STAGE、UAT、PROD）が必要です。
一般的なリリースビルドを持つようにクライアントをリファクタリングし、必要なクライアント固有の構成をサポートするためにサーバー側の処理に依存することを検討しています。これは当然の選択のように思えますが、同じ状況にある他の人々がそれをどのように処理したかを確認したいと思います。
さまざまなオプションがいくつもありますが、最適なオプションは、特定の（これまでよりもはるかに具体的な）状況によって異なります。
ビルドスクリプトの一部として、環境ごとの個別の構成ファイルを作成します。次に、展開スクリプトでデフォルトの（通常は空の）ファイルを正しい環境に置き換えます。
構成は1つだけですが、置換トークンを使用し、 [〜＃〜] escape [〜＃〜] のような構成管理ツールまたは Nolio のようなリリース自動化ツールを使用します。展開中にそれらを置き換えます。
アプリケーションサーバーの一部として構成APIを実装します。クライアントは、初期ロード中に現在の設定を要求できます。
クライアントに構成の依存関係はまったくありません。サーバーにそのAPIの動作内でそれを処理させ、クライアントの唯一の「設定」をさまざまなAPIのベースURLにします。
もっと多くのオプションがあるかもしれませんが、それらは明白なものです。そして、私が言ったように、どちらがあなたに最も適切であるかはあなたの正確な状況に依存します。あなたはまだ特定のものを推薦するのに十分なことを私たちに話していません。