2

私は現在、会社の大きなプロジェクトに取り組んでおり、行き詰まっています。TFS 2012 を使用しており、いくつかの分岐があります (Dev => Main => pre-prod => prod)。

プロジェクトが本番段階にある場合、バグが発生した場合はパッチを適用します。これは、バグ修正の影響を受ける DDL のみを提供することを意味します。

これを行うには、バグの修正を担当する開発者が自分のコードをチェックインし、変更セット番号を教えてくれるので、チェックインによって影響を受けるファイルが何であるかを知り、配信する必要がある dll を推測できます。

そして、私の問題はここにあります。変更セット番号のおかげで、これらの DLL の名前をどのように知ることができますか? 現在、すべての .csproj を解析しており、変更セット ログにあるファイルが csproj に存在するかどうかを調べています。はいの場合は、AssemblyName (DLL の名前がわかります) を探しています。

しかし、私はそれを文字列として解析しているので、これは私にとっては良くありません。信頼できず、進化的でもありません。

もっと良い方法がある場合 (または既に書かれているものでさえ :)) どうぞ ;)

ありがとう ！

4

2 に答える 2

0

アプリケーションには多くのコンポーネントがあります。

問題は、一部の DLL が複数のコンポーネントに含まれていることです。実際、彼らは完全に独立しているわけではありません。

さらに、アプリには 2 つの主要なブリック (多くの小さなブリックで構成されています) があります: ランチャー + AppFabric。Launcher はクライアント側のアプリで、AppFabric はサーバー側のアプリです。私の目標は、最後のビルド以降に変更されたブリックのみをデプロイすることです。

だから私の質問は次のとおりです。最初に戻ってすべての.csprojなどを解析することを意味するため、DLLがどこにあるかに関係なく、このアプリを展開するためのアドバイスは何ですか?

参考までに: 私が展開しているアプリの重量は ~175Mo (開発者 10 人 + 機能 5 人) で、現在 6 年間開発中の非常に大きなプロジェクトです。

于 2013-01-03T10:20:05.433 に答える
0

実際には、Diff だけでなく、すべての DLL を展開する必要があります。アプリケーションに多数の個別のコンポーネントがある場合は、コンポーネントを 1 つだけデプロイすることをお勧めしますが、それが機能するには具体的なインターフェイスが必要です。

あなたが話していることを達成するための最良の方法は、ビルド サーバーを使用してすべての DLL を同時に作成することです。TFS から Cruse Control や Hudson まで多くのオプションがありますが、それらはすべてソフトウェアの特定の「ビルド」を作成します。これにより、パッケージ化されたソフトウェアの新しいバージョンを展開するために必要なすべてのファイルが (好きなように) なり、各段階で DLL を再コンパイルまたは変更することなく、ビルドをプッシュするようにすべてが連携して動作することが保証されます。ゲート (開発、テスト、QA、PreProd) と本番環境へ。

バグを修正する場合、たとえ 1 つの DLL しか表示されていなくても、すべての DLL をデプロイする必要があります。それらはそのパッケージで一緒に動作することが知られているからです。

これは、分岐や変更セットによって解決できるものではありません。ビルドが必要です...

于 2013-01-01T18:44:40.877 に答える