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

Question

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

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

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

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

Answer 1

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

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

所以我认为没有理由做一个大型构建（仅在发布版本上），但是单独的构建将更容易使用（对于QA，以及仅在某些部分工作的开发人员）。第二个问题是时间问题。例如，要在一个解决方案中完成所有项目的完全构建，在四CPU 8gb ram上需要大约10分钟，但是使用Accounting部分或Enrollment部分进行构建只需要1分钟 - 这对我来说很重要。试着想象一下这个过程，在一张纸上画画，它变得清晰 - 做什么，为什么做。

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