複数のテスト環境(および本番)のアプリ構成を維持するためのベストプラクティスは何ですか?
現在、すべての構成をコードリポジトリ(bitbucketサーバー)に保持しています。構成は、/ configフォルダー内のテキストファイルで、各テスト環境(例:config/SIT、config/UAT、config/PROD)のサブディレクトリがあります。
問題は、これは非常に繰り返しが多く(DRY以外)、人為的エラーが発生しやすいことです。
異なるgitブランチを使用して同じ設定ファイルを維持する方が理にかなっていますか?それとも、私が見なければならない他のツールや方法はありますか?
私の見解では、別々のファイルで別々の実行環境を定義する必要があります。春のようなapplication-test.yml
、application-local.yml
、application.yml
など。1つだけ変更することで実行を切り替えることができます(正確な呼び出しコマンド)。
重複する設定が1回だけ宣言されるように記述ファイルを配置するかどうかは、独立した問題です。これは、(Springのような)デフォルト/オーバーライドメカニズムを使用するか、明示的なinclude
sを使用することでも、実行する価値があります。
ビルドとデプロイメントのアイデアを頭の中で分ける必要があります。
インターネットがなく、顧客にCD ROMをポストし、顧客がインストールして構成することを想像するのが最善です。
あなたはビルドソースコードを書き、CDを焼きますROMバージョンXで
顧客Deploysバイナリをサーバーに配置し、環境に合わせて構成します。
(コードを使用して)ソース管理に構成を配置することで、顧客が構成をどのようにしたいのかわからないときに、実質的にCDに書き込みます。
構成を別の1つまたは複数の展開スクリプトに入れれば、投稿でCDを受け取ったばかりの顧客の立場に踏み込むことになります。
次に、環境ごとに展開スクリプトまたは変数を設定し、同じバイナリバージョンのソフトウェアに対して複数回実行できます。
Octopusデプロイなどのデプロイメントスクリプトを管理できる製品が市場に出回っています。