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

Question

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

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

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

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

Answer 1

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

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

那样：

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

这个想法是：

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

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

Answer 2

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

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

Answer 3

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

1. 构建脚本
2. 构建依赖关系 - 要在构建计算机上安装的东西
3. Libraries - LIB，DLL，...直接从项目中引用
4. 文档来源 - 帮助来源
5. 来源
6. 部署脚本

然后来源以

组织
1. 管理员 - 管理控制台和脚本
2. 数据库 - 架构，脚本，初始数据
3. 通用
4. 网络
5. NTServices
6. 服务 - REST / SOAP服务
7. BizTalk - 您为产品特定的内容命名