6

在我的日常工作解决方案中，我们大约有 80 个项目。该解决方案包含 4 个不同的网站、业务逻辑和基础设施组件（例如扩展方法、各种实用程序、存储库基类等）。

该解决方案效果很好，但是如果我们将测试项目添加到解决方案中，我们很容易通过 100 多个项目，这使得使用该解决方案非常乏味。

在我寻找解决方案的过程中，我对 Nuget 非常感兴趣，我开始想知道它是否可以帮助我们。

想法是将庞大的解决方案拆分为更小的原子片段，其输出将是一个 Nuget 包，以上传到私有 Nuget 存储库。

网站将引用绑定到该特定网站的类库以外的包。

从 CI 的角度来看：

每个包解决方案都应该是原子的。

  • 它应该能够获取它的引用（其他 NuGet 包，来自官方提要和私有提要）；
  • 建造
  • 运行它的测试
  • 组装一个包
  • 将新包上传到存储库

产品解决方案（比如网站）应该在以下之后构建：

  • 提交他们的代码
  • 私有存储库上 NuGet 包的更新

有什么建议吗？或者也许是一种更好的方法来实现这个巨大的解决方案的分裂？

4

2 回答 2

6

使用包管理（在 Windows 上：NuGet）当然是一种可靠的方法。您可以“免费”获得依赖关系解析，并且可以利用语义版本控制仅通过包版本号将有意义的信息传达给包消费者。

但是，NuGet 实际上是一些更基本模式的特定实现：

  1. 仅构建已更改的代码
  2. 将系统分解为小的、可管理的单元
  3. 不要建立“框架”

从您的问题来看，听起来您正在构建比必要更多的代码，并且您的代码的模块化程度低于应有的程度。使用 NuGet 模块化您的代码将有助于实现这三种模式（当然是 1 和 2 - 您需要为 3 采取额外的步骤）。

应用这些模式也将有助于@Fede（对于谁 - 使用 C 和 C++ 代码 - NuGet 不适用）。通常，通过使您的软件更加模块化（同时避免构建单一的、无所不知的“框架”，通常称为 *.Library.dll 或 *.Common.dll 等），您将获得更好的构建架构。

最终，每个“块”代码（Visual Studio 术语中的项目或解决方案）都应该为单个开发人员所理解；如果它太笨重或复杂，请将其拆分。项目、解决方案、.cs 文件等都是对人类的抽象，而不是对机器的抽象，因此它们之间的大小和关系应该反映我们人类的能力和理解的需要。走得太远将导致需要更改多个包以完成单个功能：在这种情况下，定义上的分离是细粒度的，您需要再次将一些代码重新组合在一起。

（披露：我是 Windows 包管理 - PackageManagementBook.com的合著者）

于 2013-10-30T02:05:59.630 回答
0

您可能可以将每个单独的网站移动到不同的解决方案。如果您使用的是版本控制工具，这可能是一个合乎逻辑的步骤，因为每个单独的项目都将单独进行版本控制，这意味着开发人员不必一次与所有项目同步。此外，各个网站应该相互独立，所以这不应该是一个麻烦的举动。

您是否有与特定“业务项目”不紧密相关的通用或通用代码？此代码可以移动到另一个解决方案，如公司框架或类似的东西。然后，每个业务项目将使用该框架的已发布版本，仅在符合业务逻辑的情况和方式进行升级。例如，如果网站 A 目前的发布计划很紧，那么引入包含重大更改的框架版本可能不是一个好主意。但是，如果网站 B 处于非关键阶段，您可能希望包含框架中的新功能并在您有一点空闲时间时处理重大更改。

我不知道 NuGet 是否可以满足您的要求，但Atlassian提供了一些工具（即 FishEye、Crucible 和 Bamboo），可以帮助您以有组织的方式实现类似的目标。注意：我不隶属于 Atlassian。

于 2013-10-09T22:43:19.937 回答