在大型解决方案上组织结构/运行“构建”的最佳实践

Question

我正在制作一个非常大的网络应用程序（目前有 70 个项目和 150k 位置，但还有很多工作要做）。

我使用 FinalBuilder 运行构建脚本。但是，构建这样一个大型项目的最佳实践是什么？构建依赖项呢？我的项目结构对代码的性能有什么影响（如果有的话）？

我以前看过一些关于此的主题，但我找不到那些。我在解决方案中看到了超过 600 个项目的解决方案线程，为了得到明确的答案，让我们想象这个系统将增长到那个规模（我想知道如何组织一个比我的最终规模更大的项目，因为这意味着我可以组织一个更小的解决方案）。

如果重要的话，系统主要使用 .NET 3.5（C#、LINQ、SQL Server 等），但也会使用 Python/Erlang。

Answer 1

我只有 40 个项目（但有几百万个 loc），我们拥有的主要最佳实践是：

• 识别项目之间的依赖关系
• 建立所有希望参与下一版本的项目使用的标签的全球列表
• 确保愿意将自己的标签发布到此全局列表中的每个项目都已从来自全局列表的配置（标签列表）中制作了该标签
• 将“官方版本”（可能会部署到生产中的版本）注册到存储库中。

这样：

• 开发人员直接针对他们依赖的其他项目的交付工作和编译他们的代码（而不是下载其他项目的源代码并在本地重新构建）。
  他们只有正确的交付，因为他们知道他们的依赖关系（即时和传递）
• 测试人员可以快速部署一组交付（来自全局标签列表）以执行各种测试（非回归、压力测试......）
• 发布管理可以将这些交付（在最终全局构建之后）部署到预生产和生产平台上

这个想法是：

• 不要在每一步都重建交付
• 仅在开发阶段构建（通过通用的统一构建脚本）
• 在发布前再次构建（用于预生产和生产平台）
• 仅针对这些交付进行编译和/或测试（而不针对针对该场合下载和重新编译的源：当您有多个项目时，这是不切实际的）

主要最佳实践：
如果您自己的项目与其他项目的交付一起使用（而不是与其他项目的本地重新构建一起使用），那么它很有可能在软件生产生命周期的后续步骤（测试、预生产）中工作，生产）

Answer 2

您是否考虑过使用 NMaven 并将 70 个项目中的每一个都作为一个模块？这将允许您控制单个模块和整个父项目的构建、打包、版本控制和发布。它还可以帮助您解决不同模块、外部库甚至版本和不同生命周期范围之间的依赖关系（例如，您在测试生命周期中只需要 NUnit，但不需要在构建中打包它）。

这可能有助于更详细地解释这些项目的外观以及它们如何相互依赖。

Answer 3

作为一个问题有点开放。让我们从我向客户建议的基本结构开始，在我拥有的分支机构内

1. 构建脚本
2. 构建依赖项 - 在构建机器上安装的东西
3. 库 - LIB、DLL 等直接从项目中引用
4. 文档来源 - 帮助来源
5. 来源
6. 部署脚本

然后Sources被组织在

1. Admin - 管理控制台和脚本
2. 数据库 - 模式、脚本、初始数据
3. 常见
4. 网络
5. NTServices
6. 服务 - REST/SOAP 服务
7. BizTalk - 为产品命名