1

数百のレポートで構成される大規模な ASP.NET プロジェクトがあります。すべての SQL クエリ (Oracle データベースに対して実行) を 3 つの Web サービスに移行中です。Web サービスは、コマンド、選択、およびレポート クエリによって分類されます。インターネットから切断されたいくつかの場所に、SQL*Server バックエンドを使用してプロジェクトのサブセットをデプロイする必要があります。したがって、データベースへのすべての接続と Web サービス内のクエリを使用すると、アプリケーションが管理しやすくなり、レポートのサブセットを取得でき、コードを変更する必要がなくなります。このプロジェクトは、Serena ChangeMan ソフトウェアを使用してソース管理されています。

問題は、何人かのプログラマーがいて、彼ら全員が Web サービス ファイルをチェックアウトして自分の項目で作業する必要があることです。分岐を実装したばかりですが、徐々に悪夢になりつつあります。毎月の生産配送があり、毎月のビルドに入るはずのアイテムが翌月まで保留されることがあります. マージは手動プロセスになりました。

私はインターネット検索を実施しましたが、「ベスト プラクティス」の優れた Web サービス アーキテクチャのホワイト ページを見つけることができなかったことに驚いています。これらの問題に直面したに違いない大企業はたくさんあります。

大規模な開発グループのほとんどは分岐を使用していますか? Visual Studio Team System Database Edition は、アプリケーションがさまざまなデータベースに接続できるようにする標準コードを提供できることを読みました。Team System を購入するのが最善の方法ですか? または、これらの問題に対処するのに役立つドキュメントがどこにあるか知っている人はいますか?

ありがとう、ローリー

4

3 に答える 3

2

この問題は、ソフトウェアの目的とはまったく無関係であるように思われます。ここでの問題は、複数の開発者が毎日作業する少数の限られた数のファイルがあることです。Serena ChangeMan ソフトウェアや TFS については、いじる以外の経験はありません。マージ/コミット モデルを使用するいくつかのバージョン管理システムの経験があります: CVSとSubversion。これらはどちらも、広く​​使用されている優れた無料のバージョン管理システムです。

マージ/コミット モデルに慣れていない場合、ここでの考え方は、単一の開発者がファイルを「チェックアウト」して変更のためにロックできないということです。誰もが任意のファイルをダウンロードして変更できます。これらの変更をソース コード データベースにコミットするときに、別の開発者がファイルに他の変更を加えている場合、リポジトリ ソフトウェアはコミットを防止します。その後、新しいバージョンがダウンロードされ、ほとんどの場合、変更は自動的に変更にマージされます。再テストしてから、そのバージョンをコミットします。このモデルは非常に成功しており、非常にスケーラブルです。

そうは言っても、マージ/コミットモデルでさえ、少数のファイルを持ち、多くの開発者がそのファイルに変更を加えるという悲しみを解決することはできません。機能をより多くの Web サービスに分割することをお勧めします。おそらく、3 つのモノリシックな Web サービスの代わりに、関連する Web サービスの 3 つのグループを作成できます。これは、マージ/コミットでバージョン管理システムを使用することと相まって、問題を解決すると思います。

CVS および Subversion サーバーは、Windows、Mac、および Linux で実行されます。それぞれに多数のクライアントがあり、多数のオペレーティング システムで使用できます。これらには、スタンドアロン クライアント、Visual Studio プラグイン、およびシェル プラグインが含まれます。もう 1 つの利点は、CVS と Subversion の両方がコマンド ラインから使用できるため、スクリプト作成 (自動ビルドを考える) がかなり簡単になることです。

于 2008-12-09T18:34:56.037 に答える
1

各開発者がチェックアウトできる個々のクラス ファイルにロジックを分割してみませんか?

于 2008-12-09T21:05:27.590 に答える
0

SOA を使用していますが、よりマージ指向の SVN も使用しています。別のソース管理システムを検討してみてはいかがでしょうか。

于 2008-12-09T18:27:51.963 に答える