CIでは、通常、新しいコピーを取り出し、リポジトリ内の変更が検出され、ビルドが開始されます。ただし、場合によっては、さまざまなサーバーのローカルリポジトリで、各サーバーに固有の構成ファイルの定数の値が異なることがあります（メールアドレスが異なる場合や、特定のサーバーでロギングが有効/無効になっている場合があります）。
私の質問は、CI哲学のこれらの変更を処理するための最良の方法は何ですか、各サーバーで新しいコピーを取り出した後、サーバー関連の変更を手動で（1回）行ってから、変更を検出する通常の手順に従う必要があるかどうかです。 SVNを介してリポジトリに
これが私の職場でのやり方です：
構成ファイルは、環境ごと、サーバーの種類ごとにSVNに保存します。これは次のようになります--DEVPROJ1
---API
----- api_config_file
--- WEB
----- web_config_file
--QAPROJ1
--- API
----- api_config_file
--- WEB
----- web_config_file
- PRODPROJ1
--- API
----- api_config_file
--- WEB
----- web_config_file
このように、PROD上のすべてのAPIサーバーはでSVNPRODPROJ1/API/api_config_fileの構成ファイルを使用し、DEV上のすべてのAPIサーバーはでSVNの構成ファイルを使用しますDEVPROJ1/API/api_config_file。
私の展開スクリプトは、環境固有の構成を考慮して各サーバーに展開します。これは、展開スクリプトに「Deployto」と指示するだけで実現でき
ますAPI:PRODPROJ1=10.0.0.1,API:PRODPROJ1=10.0.0.2。次に、スクリプトはSVNのPRODPROJ1からAPI構成を取得します。
ご覧のとおり、すべてのAPIに汎用構成ファイルを使用しています。各APIで、ローカルIPアドレスなどの特定の変更が必要になる場合があります。これらは、インストール時にデプロイメントスクリプトに置き換えられます。同様のアプローチを使用できますが、環境（DEVPROJ1、QAPROJ1）で区切る代わりに、IPアドレスまたはマシン名で区切ることができます。
いずれにせよ、ランダムなサーバーで個々の変更を探すのではなく、変更を簡単に追跡および検証できるSVNにすべての構成を含めることを強く望んでいます。
もちろん、これらの構成ファイルの保守は手動のプロセスになります。