我们的开发团队正处于 CI 可以减轻我们痛苦的阶段。所以过去两天我一直在研究 CI 解决方案，基本上可以归结为 2 个选项：
我做了一些认真的阅读，并比较了两者，我倾向于 TeamCity。 这不是比较问题
我们的团队有多个解决方案，每个解决方案都包含多个项目。我们当前的构建过程是 vanilla....
发布并复制到 DEV/QA/PROD。
唯一让我有点困惑的是 TeamCity 的构建配置。使用免费版本，您可以获得 20 种构建配置。我也没有安装，所以我不确定构建配置是如何工作的。
一个构建配置可以被多个项目共享，还是每个项目都必须有一个构建配置？
这最终会破坏交易，因为我们有近 40 个解决方案，每个解决方案至少有 3 个项目。
如果构建配置直接链接到项目，那么这意味着我们至少需要 120 个构建配置。这对管理层来说并不容易。
谁能让我更深入地了解 TeamCity 的构建配置是如何工作的？
【问题讨论】：
标签： teamcity
构建配置与项目没有一对一的关系，我们在一个解决方案中有 100 多个项目，并且只有 3 个构建配置，测试、夜间和发布。
一个构建配置可以包含多个构建步骤。
这些构建步骤中的每一个都可以执行一个操作，可以是运行 msbuild、脚本、单元测试、章鱼部署等。
如果您在解决方案或构建项目中设置了不同的目标，您可以在配置中包含多个构建步骤，在解决方案中构建不同的项目集。
如果您真的出于某种自虐的原因想要这样做，您可以使用一个构建配置来构建您的所有 40 个解决方案。但是，其难易程度可能取决于您获得它们的方式版本控制。
TeamCity 有一个名为 VCS Roots（版本控制系统）的概念。
如果您想在单个构建配置中构建多个解决方案，则必须设置 multiple VCS roots for the Configuration（如果它们位于单独的存储库中），或者您可以设置拉取存储库的脚本。
如果可能需要一起构建的相关解决方案位于同一个存储库中，那么您可以使用一个 VCS 根目录。
【讨论】：
But the ease or difficulty of that may depend on how you've got them version controlled. 我们同时从 SVN 迁移到 GIT。您介意解释一下版本控制将如何影响配置吗？哈哈哈......必须先去谷歌masochistic，我相信我们都患有这种情况......
【讨论】：