多个解决方案/repo/project的理想cruisecontrol.net svn目录结构

在我们的网络代理店，我们有多个客户。我们使用SVN，但不使用CI。我想改变这一点并建立CC.NET，但我很难启动它，因为我无法决定最好的方法。我在这里有机会以正确的方式重组事物，我想抓住这个机会，但我无法制定出“理想”的结构

大多数客户端都有一个简单的结构，例如，每个客户端都有一个包含一个解决方案/网站的存储库。从长远来看，无论我选择什么，都应该很容易为这些较小的项目设置

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

但是，我们的一个客户更大，拥有多个存储库、解决方案和网站，在某些情况下，这些存储库、解决方案和网站跨多个存储库共享公共库。此外，该客户机的一些解决方案具有项目引用，其中实际项目只不过是很少更改的包装。对我来说，构建这些项目，然后只包含程序集引用是有意义的

我目前正在考虑下面的结构，但我怀疑这会使事情复杂化，而不仅仅是帮助，特别是对于多个装配级别。我认为我应该删除顶级程序集，它将位于任何客户机存储库之外，并且只接受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复制到客户机的Assembly文件夹中，使更新版本可用于依赖它的任何其他项目

---

我把事情复杂化了吗？这种设置的理想回购/解决方案/项目/目录结构是什么？

结构

我并没有遇到过与你完全相同的情况，但一旦我们遇到类似的情况，我想——我们为同一个客户做了多个项目。这些项目实际上是相似的——它们有相似或相同的文件夹结构，它们大多使用相同的外部库等等

在某个时候，我们还决定将所有这些库放在一个地方，并使它们可供所有项目使用。因此，在我们的案例中，我们有以下结构：

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

然后，对于每个项目，我们都使用了svn:externals特性，在这里我们引用了项目所需的任何附加库，这些库可以在参考资料中找到。
内部是我们自己的图书馆。外部第三方

这样我们就可以在一个地方控制所有的依赖项。当然，更新每个项目中的特定引用是手动过程——这没关系，因为我们希望确保新库不会生成任何内容，有时我们需要一些修改版本等。因此，并不建议对每个项目进行自动更新。虽然可能很容易做到

后来，一些内部引用被转换成nuget包，在构建之后，我们将它们放在共享位置上，在这里，只需从VisualStudio单击一下就可以轻松地进行更新

CCNet

另一个要考虑的是不同项目的CCNET配置。由于每个项目都有相似的结构，所以制作每个项目的副本和修改几个属性（解决方案文件名、存储库路径等）很容易，甚至有一些简单的应用程序可以帮我做到这一点

然而，现在我要使用更多的巡航控制的预处理器功能和变量定义和覆盖

这意味着创建一些基本模板，其中包含每个项目更改的所有属性，并为每个项目覆盖这些属性。通过这种方式，您可以轻松添加具有类似配置的新项目

对我来说，这一点至关重要，因为如果你有多个项目，每个项目的构建方式都不同，那么CI很快就会失控，导致糟糕的事情。。。因此，一致性是关键。或者是给我们的：）

//多个客户端引用的第三方/通用程序集， //例如NUnit、MVC：

[卖方名称] [图书馆名称] [版本号]

您已经打开了一个称为“如何处理我的二进制依赖项”的蠕虫罐

并试图找到一个SVN解决方案来处理这个问题

那么你是想找出快速解决办法？或者你准备好投入一些时间了吗

Apache的“Ivy”自2005年以来一直在处理二进制依赖性问题。“Nuget”是几年前加入的

让我们举一个简单的例子

您有一个名为“MyPDFHelper.dll”的第三方库（最初版本为1.0.0.1）。 您有2个解决方案，每个解决方案包含3个项目。（与sln和csproj相比）

PDFHelper发布了MyPDFHelper.dll的新版本，1.0.0.2。没有破坏性的变化，一切都很酷

PDFHelper发布了MyPDFHelper.dll的新版本，2.0.0.1。 与突破性的变化

Sln2/CSProjX上的开发人员希望使用MyPDFHelper.dll，2.0.0.1。 但这将如何影响Sln1/CSProjA，因为他们没有计划从1.0.0.1进行更新

显然，您已经看到了这个问题，因为您有[VersionNumber]

但这里有一个哲学问题。 SVN是为源代码（基本上是文本文件）创建的，还是作为源代码和二进制存储库的组合

Ivy和Nuget是二进制存储库

现在，我使用常春藤（即使是在微软的世界里），因为我在“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

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

\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