spring - プロファイル固有のプロパティと環境変数

Question

Spring-boot を使用すると、さまざまな環境の構成パラメーターをプロファイル固有のプロパティ ファイルに保存できますが、これにより構成がコードの一部になり、12 要素の原則では推奨されません。

むしろ、12 -factor は環境に構成(ここでの構成とは、環境によって値が異なるパラメーターを具体的に意味します) を保存することをお勧めします。

環境とプロファイル固有のプロパティファイルに構成を保存することの長所/短所は何ですか?

Answer 1

コードでの構成

長所：

1. すべてのプロパティが 1 つの場所にあるため、チームの全員が簡単にアクセスできます。すべての構成が 1 か所にあると、さまざまな環境を比較しやすくなります。
2. バージョン管理システムは、環境プロパティへのすべての変更を追跡します。変更の理由は、コミット メッセージに記述できます。
3. 自動化されたテストを使用して、ビルド プロセス中にプロパティの正確性を検証し、無効な構成でアプリケーションを起動することを回避できます。

短所：

1. 構成を変更すると (単一の環境であっても)、アプリケーション全体を再構築する必要があります。
2. バージョン管理システムは、機密性の高い認証情報 (データベースのパスワードなど) を保存するために使用される場合があります。暗号化された形式であっても、そのような値を保持することは危険です。
3. 組織が通常の開発者に対して運用環境へのアクセスを制限し、この役割専用の特別な運用チームを持っている場合、開発チームはコード リポジトリに配置するために必要なすべての構成の詳細を持っていない可能性があります。

環境での構成

長所：

1. 構成を変更しても、追加のアプリケーションの再構築は必要ありません。
2. 機密情報はバージョン管理システムに保存されません。
3. ランタイム構成の更新を実装できます。

短所：

1. アプリケーションの開始時に構成を検証する必要があります。展開が自動化されておらず、開発チーム以外の誰かによって実行されている場合は特に重要です。
2. 構成変更の履歴は、バージョン管理システムを使用するほど明確ではない場合があります。コードと構成の変更の間の接続が失われます。
3. 問題が発生したときのアプリケーションの正確な構成を知らなければ、バグの再現は不可能な場合があります。外部構成の変更の追跡は、より複雑なタスクです。

白黒ではありません。両方のアプローチを組み合わせた妥協案をいつでも使用できます。構成の一部はソース コードと一緒に保持するのに適している場合がありますが、別の部分は外部に保持する場合があります。プログラミングではいつものように、それはあなたのニーズに依存します。