在我的日常工作解决方案中，我们有大约80个项目。此解决方案包含4个不同的Web站点，业务逻辑和基础架构程序集（如扩展方法，各种实用程序，存储库基类等）。
解决方案非常有效，但如果我们将测试项目添加到解决方案中，我们很容易通过100个项目，这使得使用此解决方案非常繁琐。
在寻找解决方案时，我对Nuget非常感兴趣，我开始怀疑它是否能帮到我们。
这个想法是将巨大的解决方案分成更小的原子片，其输出将是一个Nuget包，上传到私人Nuget存储库。
网站将引用除绑定到该特定网站的类库以外的软件包。
从CI的角度来看：
每个包解决方案都应该是原子的。
产品解决方案（比如网站）应该在以下之后构建：
有什么建议吗？或者可能是实现这个巨大解决方案分裂的更好方法？
答案 0 :(得分：5)
使用包管理（在Windows上：NuGet）肯定是一种可靠的方法。您可以“免费”获得依赖性解析，并且可以利用semantic versioning仅通过包版本号将有意义的信息传递给包装消费者。
然而，NuGet实际上是一些更基本模式的具体实现：
从您的问题来看，听起来您正在构建超出必要的代码，并且您的代码模块化程度低于可能的代码。使用NuGet来模块化你的代码将有助于实现这三种模式（当然是1和2 - 你需要采取额外的步骤3）。
应用这些模式也有助于@Fede（对于谁 - 使用C和C ++代码 - NuGet不适用）。通常，通过使您的软件更加模块化（但避免构建整体的，无所不知的'框架'，通常称为* .Library.dll或* .Common.dll等），您将实现{{3} }。
最终，单个开发人员应该能够理解每个“代码块”代码（Visual Studio术语中的项目或解决方案）;如果它太笨重或太复杂，请将其分开。项目，解决方案，.cs文件等都是人类的抽象，而不是机器，因此它们之间的大小和关系应该反映我们的人类能力和理解需求。将太多远远将导致需要更改多个包以完成单个功能：在这种情况下，按定义分离是粒度的，您需要将一些代码重新组合在一起试。
（披露：我是Windows软件包管理的合着者 - better build architecture）
答案 1 :(得分：0)
您可以将每个网站移动到不同的解决方案。如果您使用的是版本控制工具，这可能是一个合乎逻辑的步骤，因为每个单独的项目都将单独进行版本化，这意味着开发人员不必同时与所有项目同步。此外，个别网站应该相互独立，所以不应该是一个麻烦的举动。
您是否拥有与特定“业务项目”不紧密相关的通用或通用代码？此代码可以移动到另一个解决方案，如公司框架或类似的东西。然后，每个业务项目将使用该框架的已发布版本，仅在何时以及如何在业务方面进行逻辑升级时进行升级。例如，如果网站A目前处于紧张的发布计划中，那么引入包含重大更改的框架版本可能不是一个好主意。但是，如果网站B处于非关键阶段，您可能希望包含框架中的新功能，并在您有一点松弛时间时处理重大更改。
我不知道是否可以通过NuGet满足您的要求，但Atlassian提供了一些工具（即FishEye，Crucible和Bamboo），可以帮助您以有组织的方式实现这样的目标。注意：我不隶属于Atlassian。