部署具有多种解决方案的分布式 .net 系统

Question

我们有一个分布式 .net 系统，它由多个解决方案组成，每个解决方案都有不同的配置和部署需求。目前所有代码都在一个 TFS 项目中，每个解决方案都有自己的构建。这些配置为触发该解决方案源代码管理文件夹中的更改。

我们正在迁移到 Team City、Git 和 rake（由于易于分支和许可成本），因此正在审查整个构建过程，但无法找到有关这方面的良好信息。我们正在努力解决的问题是：

1. 我们应该有单独的构建还是一个大型构建？需要构建和部署所有解决方案才能使系统正常运行，但最好有小型构建，因为它们快速且易于调试。有些解决方案比其他解决方案更“独立”。我们目前的做法主要是在我们想要部署到测试或生产环境时将所有构建排入队列，但有时我们只是将单个解决方案排入队列，如果这一切都发生了变化。

2. 我们应该将所有解决方案存储在一个存储库中，还是应该为每个解决方案创建一个存储库？我们使用了一些共享项目和 dll，它们如何与单独的存储库一起使用？

Answer 1

存储存储库、执行构建和部署实例的方式有很多种。他们中的许多人是对的。从我的实践来看，你使用什么技术以及构建和部署什么工具并不重要。因此，提出影响这些过程的问题很重要：

• 防止弄乱可分离的解决方案/项目（作为独立的）。 如果一个项目在几个解决方案之间共享，那么最好为它创建一个单独的存储库。只需将依赖解决方案/项目的关系添加到此；
• 防止在为不同目的生成不同构建期间出现问题（换句话说，配置管理）。 您可以为此调整 TeamCity（主要用于在每次“提交”或基于时间的计划后构建和部署自动化），或者使用一些简单但功能强大的实用程序，例如具有预定义配置的 NAnt。

所以我认为没有理由进行大型构建（可能仅在发布时），但单独的构建会更易于使用（对于 QA 和仅在某些部分工作的开发人员）。第二个问题是时间。例如，要在一个解决方案中对所有项目进行完整构建，在 Quad cpu 8gb ram 上大约需要 10 分钟，但要使用会计部分或注册部分进行构建只需要 1 分钟 - 这对我来说很重要。试着想象这个过程，在一张纸上画画，然后就清楚了——做什么，为什么做。

所有意见仅基于我的实践，在成功的项目中，每天/晚上都在经历变化，并且有数十种配置（您的构建）。