問題タブ [configuration-management]

PayPal の実装用に新しい C# プロジェクト (非 Web) を作成しました。次のような一連の構成文字列があり、それらを保存する最良の方法を見つける必要があります。私が作成したさまざまなラッパー クラスは、これらの文字列を使用しています。また、これはあらゆる Web プロジェクトやバックエンドで使用できるプロジェクトです。そのため、他のアプリケーションが必要としないように、これらすべての文字列キーを PayPal C# プロジェクトに集中させて維持するための優れた方法が必要です。私のラッパー プロジェクトを使用している他のアプリは、これらの文字列について何も知らないか、必要があります...私のプロジェクトがそれらを保存します。

それで、どこ？C# 非 Web プロジェクトで Web.Config を使用する必要がありますか? アプリ構成を使用しますか? それらをDBに保存しますか（いいえ、悪い考えです）。または、たとえば Constants.cs クラスに定数として保存しますか?

それらを定数クラスに格納することが安全かどうかもわかりませんか? ここでの私の最良のオプションは、web.configまたは何らかの構成を非Webプロジェクトに追加し、そこに保存することです。

私のシナリオ

複数の個別の実行可能アプリケーションから呼び出されるクラス ライブラリがあります。このクラス ライブラリは、アクセスするデータベース サーバーのアドレス (およびその他の多くの構成オプション、認証情報など) を知る必要があります。クラス ライブラリとは別に、これらの構成オプションを把握して設定する必要がある構成および管理アプリケーションがあります。

私の質問

これらのユーザー固有の構成オプションを Windows レジストリに格納するのが一般的な方法ですか、それとも、クラス ライブラリに典型的な 'App.config' XML アプローチを使用し、構成ツールがそれを変更および修正できるようにすることが望ましいですか?

私はレジストリのアプローチに傾倒していますが、多くの人がそれを使用しないという意見を持っていることを知っています. あなたならどうしますか？

簡単な Web アプリの開始点として、ASP.NET Web サイト Small Business スターター キットを使用しています。いくつかの理由（VisualSVNとのより良い相互作用など）で、WebサイトからWebプロジェクトに変換したかったのです。新しい ASP.NET Web アプリケーションをゼロから作成しました...次に、すべてのファイルをエクスプローラーでコピーして貼り付け、プロジェクト -> Web アプリケーションの作成を行いました。私が修正したいくつかの初期エラーがありましたが、今では元の「アイテム」ページでこれを取得しています:

SmallBusinessDataProviders の構成セクション ハンドラーの作成中にエラーが発生しました: タイプ 'FooWeb.ProviderSettingsValidation' は 'System.Configuration.IConfigurationSectionHandler' から継承されません。(C:\Projects\FooWebFacing\FooWeb\FooWeb\web.config 5 行目)

IConfigurationSectionHandler を実装する必要があるというこのエラー メッセージが表示される理由を知っている人はいますか? ConfigurationSection から継承するだけで、ASP.NET Web サイト プロジェクトで問題なく動作しました...そして、その Web サイトは .NET 3.5 としてビルドされました。プロジェクトを .NET 2.0 に変更しようとしましたが、それでもうまくいきませんでした。VS 2008 Developer Edition を使用しています。助けてくれてありがとう。

編集: 明確にするために: 同じ正確なコードが Web プロジェクトとしては正常に機能しますが、Web アプリケーションとしては機能しません。このエラーは、元のプロジェクトに関係なく、まったく意味がありません。これがどのように起こるか誰にも手がかりがありますか?

私は4つの製品を持つ製品スイートに取り組んでいます。現在、すべての構成データはXMLファイルまたはプロパティファイルのいずれかにあります。このアプローチは、環境（本番、開発など）ごとに異なる構成ファイルを管理する必要があるため、維持できません。

では、構成データを処理するための最良の方法は何ですか？

また、これを別のモジュールにモジュール化できますか？すべての製品がこのモジュールを使用できるようにします。プロパティファイルは使いたくありません。すべての構成固有のコードを新しい構成モジュールとして移動し、すべての構成データをデータベースに保持できるソリューションを探しています。

ASP.NET 3.5

ソリューション全体のクラスは ConfigurationManater.AppSettings[""] を参照して appSettings を取得しました (web.config から)。

私たちはそれに満足していないと判断しました。コード内で appSetting のキー名をタイプミスする人がいて (問題なくコンパイルされました)、使用状況を追跡するのが面倒でした。そして、どこでも同じ appSettings を参照しているため、コードベース全体に重複した文字列があります。

そのため、ConfigurationManager を参照できるのは 1 つのクラスのみであり、ソリューションの残りの部分は、特定の appSetting の値が必要なときにそのクラスを参照することにしました。ConfigurationManater.AppSettings[""] は静的だったので、単一の Settings クラスから一連の静的な読み取り専用プロパティを公開しました。

テストで設定をモックする必要があるまでは、これでうまくいきました。モッキングを可能にするインターフェースを作成しました (これは何かの間違いでしたか?)。

そして今、設定値を使用するオブジェクトの依存関係として ISettings インスタンスを注入しています (クラス/インターフェイスは、誰もが問題なく参照できるプロジェクトにあります)。

既存のインスタンス (Global.asax など) を挿入できない場所では、静的フィールドに新しいインスタンスを構築します。

これらすべてを考慮して、何を変更することをお勧めしますか? また、その理由は何ですか?

私は、5 人の開発者と 1 人の QA 担当者のグループで構成される小さな開発ショップで働いています。私たちは TFS を使用しており、このツールの使用方法をより洗練させる必要があります。

現在、開発チームは毎晩コードをチェックインしています。毎晩のビルドが実行され、出力がネットワーク共有にプッシュされます。私たちの QA 担当者は、このビルドを翌日のテストに使用します。トランク コードベースからのビルドには、QA プロセスを妨げる問題やバグが含まれていることがあります。これは過去には大きな問題ではありませんでしたが、現在は、QA 担当者が安定した QA でテストする状態にしたいと考えています。建てる。

したがって、ブランチ (QA と呼びます) を作成する必要があると思います。開発者はトランクから開発を続けますが、QA 担当者は QA ブランチのコードから作成されたビルドを使用します。

簡単そうに見えますが、コードレビューも始めました。したがって、コード レビューが行われたコードのみを QA 部門に昇格させたいという別の要望もあります。各開発者は TFS アイテムを処理し、変更セットをチェックインするときに、チェックインされたコード ファイルと TFS アイテムの間のリンクを作成する TFS アイテムに対して実行します。最終的に、TFS アイテムは完成し、コード レビューの準備が整います。TFS アイテムに添付されたすべてのコードがレビューされます。これらのファイルのバージョンを QA ブランチに昇格するにはどうすればよいですか?

QA ブランチでバグが見つかった場合は、QA ブランチで修正し、変更をトランクに戻す必要があります。TFSにはこれを自動的に行う方法があると思いますよね？

簡単に言えば、かなり標準的なビルドおよび CM 環境を実現したいと考えていますが、TFS でこれを実現する方法がわかりません。上記の状況を踏まえて、特定のニーズに対応する書籍または Web サイトを誰か指摘してもらえますか? CM 理論や TFS に深く入り込むことなく、これを実現したいと考えています。

あらゆる提案に感謝します！

ありがとう、ジョン

私たちは新しいアジャイル ショップであり、他の人が見たことを願っている問題に遭遇しています。

私たちのプロセスでは、トランクは統合ブランチと見なされます。リリース可能である必要はありませんが、他の人が分岐できるように安定していて機能的である必要があります。新しい開発のためにトランクの機能ブランチを作成します。すべての作業とテストは、これらのブランチで行われます。個々のブランチは、必要に応じてプルアップし、他の機能が受け入れられ、コミットされているため、トランクとの統合を維持します。しかし今では、多数の機能ブランチがあります。それぞれが焦点を絞っており、ライフサイクルが短く、完了するとトランクにプッシュされるため、ブランチの必要性については議論せず、アジャイルになるように努めています。

私の問題はここにあります: トランクにプッシュする前に、ブランチがライフサイクルの終わりにトランクからプルアップし、検証、回帰テストを完了し、すべての構成の問題を処理する必要があります。トランクに再統合したら、少なくともビルドと自動スモーク テストをお願いします。ただし、現在、トランクの検証についてプッシュバックを受けています。議論は、開発者が機能ブランチでの作業を既に完了しているため、コードをマージでき、QA 検証手順を必要としないということです。したがって、追加のテストは必要ありません。私は何度も「頭のない」マージが失敗したことを経営陣に思い出させようとしました。この解決策は、ビルドと回帰テストの代わりに、開発者に機能ブランチと新しくマージされたトランクを比較させることです。彼らが考えていたそのプロセスは、私が求めた回帰テストに取って代わるものでした。では、トランクに再統合するときに必要なものは何ですか? このステップを削除して diff に置き換えると、どのような問題が発生しますか? アジャイルを維持するためのコストは、ブランチの統合による追加作業ですか?

ご意見ありがとうございます。ローンCM

多くのサードパーティの依存関係を持つ大規模なアプリケーションのプロジェクト要件が含まれている場合：

1）元のビルドが実行されてから25年間、任意のビルドのビットごとの同一コピーをソースから複製できる構成管理システムを維持します。

2）ビルドをコンパイルして依存関係を解決するためのビルドツールとしてMaven2を使用します

これらの要件を満たすには、どのようなプロセスに従う必要がありますか？

現在、すべてのWebアプリは、個別の構成ファイルを使用してデプロイされています。

これには、1つの構成ファイルをスワップアウトするだけでよい場合でも、誰もが精通していると確信しているという欠点があります（XMLを検索せずにデプロイしたものがその1つであるかどうか疑問に思います）

基本的に「本番モードで実行中」と表示されるロギングをアプリケーションに追加し、デプロイされたサービスとそれらが動作しているモードの説明を追加したいと思います。

等々...

これは、従来の展開（サーバーに戦争を起こす）を使用してSpringで可能ですか？展開とソフトウェア構成を管理するために、他にどのようなことをしますか？

そうでない場合、他にどのような方法で同様のことを達成できますか？

Subversion を RCS として使用しています。プロジェクトの新しいバージョンが完成すると、常にそのタグ (トランクのコピー) を作成します。このタグ付けされたディレクトリが誤って変更されないように保護する方法を知っている人はいますか?

現時点では、回避策としてすべてのファイルをロックしています。ただし、このシルは、ロックされたユーザーがファイルを編集できることを意味します。

より良い解決策はありますか？