0

私たちの Web エージェンシー ショップには、複数のクライアントがいます。SVN を使用していますが、CI は使用していません。これを変更してCC.NETをセットアップしたいのですが、最適なアプローチを決めることができず、うまくいきません。ここで物事を正しい方法で再構築する機会があり、それを利用したいのですが、「理想的な」構造を見つけることができません。

クライアントのほとんどは、クライアントごとに 1 つのソリューション/Web サイトを含む 1 つのリポジトリなど、単純な構造を持っています。長期的には、これらの小規模なプロジェクトを簡単にセットアップできるものを選択する必要があります。

ただし、当社のクライアントの 1 つは大規模で、複数のリポジトリ、ソリューション、および Web サイトがあり、場合によっては複数のリポジトリで共通のライブラリを共有しています。また、このクライアントのソリューションの一部には、実際のプロジェクトがめったに変更されないラッパーにすぎないプロジェクト参照があります。私にとっては、これらのプロジェクトをビルドしてから、代わりにアセンブリ参照を含めることは理にかなっています。

私は現在、以下の構造のようなものを考えていますが、特に複数のアセンブリ レベルでは、問題を解決するよりも複雑にしているのではないかと考えています。クライアントリポジトリの外部にあるトップレベルのアセンブリを削除し、MVC または NUnit を各クライアントの複数のフォルダーに格納する必要があることを受け入れる必要があると思います。ビルド サーバーだけでなく、開発者のマシンでのこの構造も考慮する必要があります。

D:/Projects

    Tools
        // Folders containing dlls and libraries relating to the 
        // CI build process, e.g. FXCop, StyleCop settings, etc.

    Assemblies
        // third party/common assemblies referenced by multiple clients, 
        // e.g. NUnit, MVC:

        [VendorName]
            [LibraryName]
                [VersionNumber]

    [ClientName]
        [Assemblies] (Possibly a new SVN repository?)
            // Third party assemblies that are used only by this client.
            // and also where the client's own shared assemblies will live
            // after a successful build, for other Projects to reference.

            [ThirdPartyVendor]
                [ThirdPartyLibrary]
            [ClientName]
                [ProjectName.dll]

        [Library/Website]
            ProjectName.sln
            CC.NET project build scripts
            [ProjectName] // The main codebase
            [ProjectName.Tests] // Unit Tests
            [Artifacts] // CC.NET Artifacts
            [Documentation] // For XML Docs that will be built nightly

ライブラリが関連するテストをビルドして完了すると、別のプロジェクトがそれに依存している場合、結果の DLL がクライアントの Assemblies フォルダーにコピーされ、更新されたバージョンがそれに依存する他のプロジェクトで利用できるようになります。

私は物事を過度に複雑にしていますか？この種のセットアップの理想的なレポ/ソリューション/プロジェクト/ディレクトリ構造は何ですか?

4

2 に答える 2

0

アセンブリ // 複数のクライアントによって参照されるサード パーティ/共通アセンブリ。 // NUnit、MVC など:

[ベンダー名] [ライブラリ名] [バージョン番号]

「BINARY 依存関係を処理する方法」として知られるワームの缶を開けてしまいました。

そして、それを処理するSVNソリューションを見つけようとしています。

それで、あなたは簡単な修正を理解しようとしていますか？それとも、それに時間を割く準備はできていますか？

.......

Apache の「Ivy」は、2005 年からバイナリ依存関係の問題に取り組んできました。「Nuget」は数年前に参加しました。

簡単なケースを考えてみましょう。

「MyPDFHelper.dll」(元のバージョンは 1.0.0.1) というサード パーティ ライブラリがあります。それぞれ 3 つのプロジェクトを含む 2 つのソリューションがあります。(VS .sln および .csproj)。

Sln1, CSProjA, CSProjB, CSProjC
Sln2, CSProjW, CSProjX, CSProjY

Sln1/CSProjA depends on MyPDFHelper.dll, 1.0.0.1.
Sln2/CSProjX depends on MyPDFHelper.dll, 1.0.0.1.

PDFHelper は、MyPDFHelper.dll の新しいバージョン 1.0.0.2 をリリースします。重大な変更はありません。すべてがクールです。

PDFHelper は、MyPDFHelper.dll の新しいバージョン 2.0.0.1 をリリースします。重大な変更があります。

Sln2/CSProjX の開発者は、MyPDFHelper.dll、2.0.0.1 を使用したいと考えています。しかし、1.0.0.1からアップデートする予定のないSln1/CSProjAにはどのような影響があるでしょうか。

[VersionNumber] があるため、明らかに、この問題は既に発生しています。

しかし、ここに哲学的な問題があります。SVN はソース コード (基本的にはテキスト ファイル) 用に作成されていますか、それともソース コードとバイナリ リポジトリの組み合わせとして作成されていますか?

Ivy と Nuget は BINARY リポジトリです。

今は (Microsoft の世界でも) Ivy を使用しています。これは、「Nuget」というフレーズが発せられる前に依存関係の問題を解決したためです。

……

これは少し異なる問題ですが、似ています。

同じ「アプリケーション」プロジェクトがあります。

Sln1, CSProjA, CSProjB, CSProjC
Sln2, CSProjW, CSProjX, CSProjY

しかし、「フレームワーク」部分を含む .sln もあります。うまくカプセル化された電子メール送信コードだとしましょう。

MyCompany.EmailLibrary.sln MyCompany.EmailLibrary.csproj (MyCompany.EmailLibrary.dll に組み込まれます)

Sln1 / CSProjB uses MyCompany.EmailLibrary.dll.
Sln2 / CSProjX uses MyCompany.EmailLibrary.dll.

独自のフレームワーク部分に重大な変更を加えるとどうなりますか?

.........

一言で言えば。

コードをソースコード リポジトリに入れる代わりに、

バイナリ リポジトリに「公開」する

この例では:

MyPDFHelper.dll, 1.0.0.1. would be published
MyPDFHelper.dll, 1.0.0.2. would be published
MyPDFHelper.dll, 2.0.0.1. would be published

次に、MyPDFHelper.dll に「依存する」各プロジェクトには、「このバージョンの MyPDFHelper.dll を使用したい」という何らかの構成値があります。

アイビー表記は次のようになります

「1.0.0+」または「1+」。

そして、2.0.0.1 が「publish」の場合、Sln2 の構成を「2.0.0+」に変更できます。Sln1 構成は「1.0.0+」で変更されません

このようにして、各 Sln (1 および 2) は、ニーズに合ったバージョンの MyPDFHelper.dll を「取得」します。最終的に (そして開発者がそうすることを選択した場合)、Sln1 は "2.0.0+" に変更できますが、開発者は、他の開発者が新しいサードパーティの dll を入れたときではなく、必要に応じて重大な変更に対処できます。ソース管理。

.........

さて、MyCompany.EmailLibrary.dll についてです。基本的に、MyCompany.EmailLibrary.sln がビルドされるたびに、新しいビルドをバイナリ リポジトリに配置します。バグ修正だけなら、いつでもバージョン「1.0.0.1」を公開 (およびオーバーライド) できますが、私は増分番号で公開することを好みます。

MyCompany.EmailLibrary.dll v 1.0.0.333
MyCompany.EmailLibrary.dll v 1.0.0.334
MyCompany.EmailLibrary.dll v 1.0.0.444

(数値は重要ではありません。数値が増加するという事実だけです。

.........

Nuget (プライベート リポジトリを使用) または Ivy (COMMAND LINE オプションを使用) をチェックアウトします。

正確な解決策はありませんが、バイナリ リポジトリの概念を紹介します。

===================編集

「ソースコード構造」に関しては、次のようにします。

\DotNet\src\v20Base\v20\
\DotNet\src\v20Base\v20\Applications\
\DotNet\src\v20Base\v20\Framework\
\DotNet\src\v20Base\v20\ThirdParty\


\DotNet\src\v20Base\v35\
\DotNet\src\v20Base\v35\Applications\
\DotNet\src\v20Base\v35\Framework\
\DotNet\src\v20Base\v35\ThirdParty\


\DotNet\src\v40Base\v40\
\DotNet\src\v40Base\v40\Applications\
\DotNet\src\v40Base\v40\Framework\
\DotNet\src\v40Base\v40\ThirdParty\

\DotNet\src\v40Base\v45\
\DotNet\src\v40Base\v45\Applications\
\DotNet\src\v40Base\v45\Framework\
\DotNet\src\v40Base\v45\ThirdParty\



Example Application
\DotNet\src\v40Base\v40\Applications\
\DotNet\src\v40Base\v40\Applications\SodaManagerSolution\
\DotNet\src\v40Base\v40\Applications\SodaManagerSolution\SodaManagerSolution.sln
\DotNet\src\v40Base\v40\Applications\SodaManagerSolution\Pres.AspNet\
\DotNet\src\v40Base\v40\Applications\SodaManagerSolution\Pres.WPF\
\DotNet\src\v40Base\v40\Applications\SodaManagerSolution\BusinessLogic\
\DotNet\src\v40Base\v40\Applications\SodaManagerSolution\DataLayer\
\DotNet\src\v40Base\v40\Applications\SodaManagerSolution\SqlScripts\

Example Framework
\DotNet\src\v40Base\v40\Framework\
\DotNet\src\v40Base\v40\Framework\MyCompany.EmailLibrary\
\DotNet\src\v40Base\v40\Framework\MyCompany.EmailLibrary\MyCompany.EmailLibrary.sln
\DotNet\src\v40Base\v40\Framework\MyCompany.EmailLibrary\MyCompany.EmailLibrary.csproj

DotNet 3.5 (および 3.0) は 2.0 の「オーバーレイ」でした。したがって、3.5 ソリューションは問題なく 2.0 dll を使用できます。4.0 は新しい CLR であり、新しい「v40Base」です。

やり過ぎのように感じるかもしれませんが、フレームワークが変更されると……大規模なソース コード リポジトリでは、どのプロジェクトが他のどのプロジェクトを参照できるかについて混乱し始めます。

于 2013-05-10T14:35:34.107 に答える
0

構造

私はあなたのような状況にあったわけではありませんが、同じような状況になったとき、同じクライアントに対して複数のプロジェクトを抱えていたと思います。実際、これらのプロジェクトは類似していました。それらのフォルダー構造は類似または同じであり、ほとんど同じ外部ライブラリを使用していました。

ある時点で、これらすべてのライブラリを 1 か所に保管し、すべてのプロジェクトで利用できるようにすることも決定しました。したがって、私たちの場合、次の構造がありました。

Client_name/  
-- References  
-- -- Internal  
-- -- External  
-- Project 1  
-- -- ...  
-- Project 2  
-- -- ...

次に、プロジェクトごとに svn:externals 機能を使用しました。ここでは、プロジェクトに必要な追加のライブラリを参照し、参照で利用できます。
内部は私たち自身のライブラリ用でした。サードパーティの外部。

このようにして、すべての依存関係を 1 か所で制御できます。もちろん、各プロジェクトの特定の参照を更新するのは手動のプロセスでした。新しいライブラリが何もビルドしないようにしたかったので、問題ありませんでした。変更されたバージョンなどが必要になることもありました。本当にお勧めしません。おそらく簡単に行うことができますが。

その後、これらの内部参照の一部が nuget パッケージに変換され、ビルド後にそれらを共有の場所に配置しました。共有の場所では、Visual Studio からワンクリックで簡単に更新できました。

CCNet

考慮すべきもう 1 つの点は、さまざまなプロジェクトの CCNet 構成です。それぞれのプロジェクトは似たような構造を持っていたので、各プロジェクトのコピーを作成し、いくつかのプロパティ (ソリューション ファイル名、リポジトリ パスなど) を変更するのは簡単で、それを行うための簡単なアプリケーションさえありました。

しかし今は、クルーズ コントロールのプリプロセッサ機能と、変数の定義とオーバーライドをもっと活用したいと思います。

これは、プロジェクトごとに変更されるすべてのプロパティを含む基本的なテンプレートを作成し、プロジェクトごとにそれらをオーバーライドすることを意味します。このようにして、同様の構成で新しいプロジェクトを簡単に追加できます。

私にとって、この点は非常に重要です。複数のプロジェクトがある場合、それぞれのビルドが異なるため、CI はすぐに手に負えなくなり、悪い結果につながります...したがって、一貫性が重要です。または私たちのためでした:)

于 2013-05-09T10:31:52.817 に答える