タグ付けされた質問 「configuration」

この質問では、例としてSpring Bootサービスを取り上げていますが、これはどのようなテクノロジーでもかまいません。 次のように仮定します。 環境（dev / QA / prod）は異なるチームによって所有されています。これは、開発者が製品構成にアクセスできないようにする必要があることを意味します。 構成（application.propertiesとしましょう）は外部化されています。つまり、バイナリの一部ではありません。 同じバイナリ/パッケージ（service.jarとしましょう）が各環境にデプロイされ、自動デプロイメントによって制御されます バイナリアーティファクト（service.jar）への変更は自動的に各環境に伝達されますが、構成への変更には依然として手動による介入が必要であり、必然的に各環境で非同期化されます。 たとえば、開発チームが環境内のapplication.propertiesにいくつかのキーと値のペアを追加するとします。これらの新しいキーを記録する最良の方法は何ですか？それで、運用チームで展開が行われるときに、追加するキーが正確にわかっているため、新しいサービスを開始し、キーが見つからないために失敗することを確認するリスクが最小限に抑えられますか？ 手動の手順が含まれることはわかっていますが、人々がこれをどのように処理し、最も効果的な方法を見つけるか知りたいです。

9 spring  development-environment  configuration  development-methodologies 

ソフトウェアの構成にDIC / IoCレジストリを使用するタイミングと、ファクトリを使用するタイミング、およびどちらのアプローチの背後にある理由も理解しようとしています。 レジストリを使用して簡単に構成できるDIコンテナー（DIC）としてStructureMapを使用しています。DICでは、実質的にすべての登録済みオブジェクトは静的です。つまり、DICが構成され、DICでシングルトンとして構成されたら、実行時に実装/インスタンスを変更/交換する必要はありません。ただし、ソフトウェア（SW）はさまざまなデバイスで実行されるため、ハードウェアを適切に構成するには、ソフトウェアが実行されるデバイスに応じてデバイス固有のレジストリを選択する必要があります。 一部のオブジェクトの構築には構成ファイルの読み取りが必要なため、構成の読み取りとオブジェクトの作成を分離するために、ファクトリを使用してこれらのインスタンスをDICに返しています。対応するプラグインタイプのファクトリゲッターをDICに登録しました。 IMotor具象型Motor1とを備えたプラグイン型があるとしましょうMotor2。これはファクトリで処理する必要があります。デバイスの構成方法を決定する方法は2つあります。 私はSWが上に実行されていることをデバイスに関する情報を渡しMotorFactory、それが正しいモータを返す、のいずれかMotor1、またはMotor2。この場合、決定のロジックはファクトリー内にあります。 DICを実行しているデバイスに応じてDICを構成し、2つのファクトリMotor1Factoryを作成します。1 Motor2Factoryつは作成Motor1し、もう 1つは作成しますMotor2。この場合IMotor、Motor1Factoryまたはのいずれかを使用するデバイス固有のレジストリに、異なるレジストリエントリが含まれますMotor2Factory。 今私の質問です：これらの2つの方法のどちらが望ましいのですか？私には、コードベース全体でどのタイプをインスタンス化するかを決定するロジックを広げているため、最初のケースは単純ではなく複雑です。一方、2番目のケースでは、コード内のファクトリの数を効果的に増やしています。これは、（ほとんど）各具象型のファクトリが必要になるためです。抽象ファクトリーがミックスに追加されると、さらに混乱します。 繰り返しますが、どちらの方法を使用すればよいですか？さらに重要なのは、どちらの方法に進むかを決定するための優れた指標は何ですか？

9 configuration  factory  ioc-containers 

状況：dbaは、DALコード全体をTFSでチェックアウトしたままにするオフサイトの請負業者です。フロントエンドの開発者として、列を追加したり、プロシージャなどを調整したりできます。この男がメールに応答して作業を行うのを待つ必要はありません。 質問：データの整合性とチーム間の平和への愛と幸福を維持しながら、より迅速で機敏な開発を可能にする推奨ソリューション/プロセスは何でしょうか？

9 asp.net  teamwork  team-foundation-server  team-building  configuration 

たとえば、悪名高いパス変数をユーザーに定義させます。どのように解釈しapppath = C:\Program Files\Appますか？ これは、プログラミング言語がホワイトスペースを無視する慣習を採用しているように見え、読みやすさのために等号の前後に残しますが、アプリケーションではホワイトスペースを含む有効な変数値である可能性があります（サフィックスであると考えてください）。 キーにも空白を含めることができますか？ アプリケーションの一般的なベストプラクティスは何ですか？私が持っている場合： key-example = value-example キーの存在"key-example"または"key-example "と値を存在"value-example"またはと解釈する必要があり" value-example"ますか？

8 user-interface  validation  variables  configuration  text-processing 

ある種の構成ファイルを必要とする小さなツールを設計しています。私の場合、構成ファイルは実際にはデータベースに近いものですが、軽量である必要があり、必要に応じてエンドユーザーが簡単に編集できるようにする必要があります。ただし、その中にも多くのものが含まれます。（特定の要因に応じて、1Mb以上になる場合があります） SQLiteなどを使用するのではなく、プレーンテキストを使用することにしました。ただし、テキストを使用する場合は、さまざまな形式にも対応する必要があります。これまでのところ、私の選択肢は XML JSON カスタムフォーマット 私のファイルのデータは非常にシンプルで、ほとんどの部分はキーと値のタイプのものです。したがって、カスタム形式はそれほど難しくありません...しかし、サポートの作成について心配する必要はありません。JSONが構成ファイルに使用されるのを見たことがありません。XMLはファイルサイズを大幅に膨らませると思います。（私はまた、一般的にXMLが嫌いです）。 この場合、どうすればよいですか？ 考慮すべき要素： この構成ファイルはWebサービスにアップロードできます（サイズが重要です） ユーザーは必要に応じて手動で編集できる必要があります（編集や読みやすさの問題） 自動的に生成および処理できる必要があります（速度はそれほど重要ではありませんが、過度に遅くはなりません） 「キー」と「値」はプレーンな文字列ですが、何でも含めることができるためエスケープする必要があります。（ユニコードとエスケープは簡単に機能する必要があります） 複数の構成ファイル。基本的に、各設定ファイルは1つの「プロジェクト」に関連付けられています

8 .net  xml  json  configuration  file-structure