1

ビルド プロセスの改善の一環として、現在、ローカル開発環境とは別のプロジェクト/ソリューション ファイルを CI 運用環境に置くべきかどうかを検討しています。

これが発生した理由は、以前のプロジェクトで経験した参照の問題のためです。頻繁に、間違った場所にアセンブリへの参照を誤って追加することがよくあります。これは、ローカル環境では問題なく動作することを意味しますが、他の人やビルド マシンでは壊れる可能性があります。

また、参照パスは csproj.user ファイルにあります。つまり、これらはソース管理にコミットする必要があるため、全員がこれらの同じ設定を共有する必要があります。

そのため、ビルドを行うときに、ローカルの開発プロジェクトではなくこれらのプロジェクトを使用するように、CI サーバーに個別のプロジェクトとソリューションを用意することを考えています。

これらの個別のファイルと、定義して従わなければならない関連プロセスを維持するためのオーバーヘッドなどの明らかな欠点がありますが、運用環境で何が起こるかを正確に制御できるという利点があります.

私が見つけられなかったのは、この主題に関するものではありません - これについて考えているのは私たちだけだとは信じられません - だから、すべての考えを歓迎します.

4

6 に答える 6

1

私はそれが時代錯誤であることを知っています。しかし、参照の問題を処理するために私が見つけた唯一の最善の方法は、フォルダーを R: などのドライブ文字にマップし、すべてのプロジェクトをそのフォルダーにビルドするか、出力をコピーすることです。次に、すべての参照は R:\SomeFile.dll などです。これにより、参照が絶対パスで追加される場合と、相対的に追加される場合があるという問題を回避できます。（「HintPath」と関係があり、あまり覚えていません）

良い点は、ビルド サーバーで同じソリューション ファイルを引き続き使用できることです。正直に言うと、開発マシンでビルドされているものがビルドサーバーと同じであるという確実性を失うため、これは絶対に必要です。

于 2008-08-21T12:10:00.857 に答える
1

私たちの最大のプロジェクト (多くのアプリケーションで構成されるシステム) では、次のような構造になっています。

/3rdPartyAssemblies
/App1
/App2
/App3
/.....

すべての外部アセンブリは 3rdPartyAssemblies/Vendor/Version/... に追加されます

依存関係の順序でビルドするために共有されるすべてのアセンブリの MSBuild スクリプトとして機能する CoreBuild.sln ファイルがあります (つまり、App2 には App1.Interfaces への参照があるため、App1.Interfaces が App2 の前にビルドされるようにします)。

すべてのアプリケーション間参照は /bin フォルダーをターゲットにします (bin/debug と bin/release は使用せず、bin のみを使用します。この方法では、参照は同じままで、ビルド ターゲットに応じてリリース構成を変更するだけです)。

Cruise Control は、他のアプリをビルドする前に依存関係のコア ソリューションをビルドします。サーバーには 3rdPartAssemblies フォルダーが存在するため、開発者のマシンとビルド サーバーが同じ開発レイアウトを持つようにします。

于 2008-08-21T08:53:31.047 に答える
0

@David-信じられないかもしれませんが、これは私たちが実際に今持っているものですが、それでもまだ問題を引き起こしています!

ただし、以前の回答で述べたように、TeamCity と複数のビルド エージェントに移行したために強制されたいくつかの変更を行っています。

このリンクの外部セクションを見て、私が何を意味するかを確認してください - http://www.dummzeuch.de/delphi/subversion/english.html

于 2008-08-21T12:04:16.643 に答える
0

通常、プロダクション用に何らかの形でビルド プロジェクト/スクリプトを作成するため、別のソリューション ファイルをまとめる必要はありません。

プロジェクト参照を使用するように全員をトレーニングし、プロジェクト ファイル構造の下に外部アセンブリ参照用のディレクトリを作成する方が簡単です。このようにして、誰もが同じ環境に従います。

于 2008-08-18T14:24:48.710 に答える
0

プロジェクト構造を変更し (SVN Externals を使用)、各プロジェクトが完全に自己完結型になりました。つまり、参照がプロジェクト ディレクトリの外に出ることはありません (たとえば、プロジェクト A が ASM X を参照する場合、ASM X は ProjectA のサブフォルダー内に存在します)。

これは私たちの問題のいくつかを解決するのに役立つと思いますが、ビルド プロジェクトをより詳細に制御できることには、まだいくつかの利点があります。

于 2008-08-21T08:40:06.307 に答える
0

これに反対することを強くお勧めします。

  1. 参照パスは .user ファイルに保存されるだけではありません。ヒント パスは、プロジェクト ファイル自体に格納されます。.user ファイルをソース管理にチェックインする必要はありません。

  2. すべての開発者が使用する (バージョン管理されている可能性がある) ソリューション/プロジェクト ファイルのセットが 1 つあり、そのリリース構成が最終的に運用環境で構築されるものであるとします。個別のプロジェクト ファイルを使用すると、一部のプロジェクト設定が微調整され、引き継がれず、本番環境に移行したときに混乱が生じる可能性があります。

これもチェックしてください：

http://www.objectsharp.com/cs/blogs/barry/archive/2004/10/29/988.aspx http://bytes.com/forum/thread268546.html

于 2008-08-18T19:09:12.880 に答える