解决方案/构建比率答案

【问题标题】：Solution/Build Ratio解决方案/构建比率
【发布时间】：2016-11-12 20:58:15
【问题描述】：

作为 DevOps/TFS/Git 的新手，我正在努力更好地理解 The Way of Things™。

刚刚完成了我的第一个成功的 TFS 构建——在通过了臭名昭著的“构建服务器上的 Visual Studio” 要求之后——我已准备好继续学习 NuGet 打包和发布管理。这很令人兴奋，我被收费了。

不过，在我走得太远之前，我想检查一下我对所有这一切的一般参与规则的理解。

除非我弄错了，似乎每个构建定义只能有一个存储库；之后，每个存储库只有一个 Visual Studio 解决方案。因此，如果我们想要为给定应用程序创建三个构建定义——Dev、Staging 和 Release——这似乎很快就会陷入困境。

我最初的印象是正确的吗？我们要为每个要推出的新应用程序制定一组新的构建定义？这是很多定义，但如果这是它应该工作的方式，我会用它。

编辑

我看到由于缺乏明确性，投票结束。我希望我的问题很清楚，但我还是会尝试改进它。

我想知道的是，正确/最有效的配置方法是否是为每个新的应用程序/解决方案创建一组新的构建定义。这似乎会很快导致构建定义膨胀（BDB），所以我希望我最初的印象是不正确的。相反，我希望有一种方法可以将多个存储库指向一组构建定义。

那将是我的确切问题，那么...有没有办法将多个存储库链接到一组 Dev/Staging/Release 构建定义？

【问题讨论】：

这可能会被关闭，因为这是一个巨大的讨论领域。我在这方面进行了广泛的咨询，对于您提出的任何问题，都没有简单、直接的正确答案。这一切都取决于业务需求、您的应用程序组合以及您组织中软件开发实践的成熟度。
@DanielMann：我明白了！因此，必须可以这样做——也就是说，将多个 repos 发送到单个构建定义。是吗？
是什么让您认为每个存储库应该只有 1 个解决方案？此外，您应该构建一个部署到所有环境的工件，因此您不应该关心 dev / staging / prod。如果您使用的是 TFS 2015，请使用 build v.next。如果您使用的是早期版本，请忘记构建 TFS，这太糟糕了。看看 Jenkins / TeamCity。
@JamesReed: 1) 如果可能的话，尽量减少 BDB。 2) 恐怕你把我弄丢了。 3）v下一个。看来我用这个躲过了一劫。
1.如果 BDB 是指构建定义膨胀，仅仅因为解决方案在回购中并不意味着您必须构建它。您可以在一个 repo 中有 50 个解决方案，并为每个解决方案单独构建。不需要单独的回购。 2. 在构建结束时，您应该有一个可以部署到任何环境的包。然后，您使用发布管理工具（MS-RM、Octopus Deploy 等）将包推送到环境并设置任何特定于环境的配置（连接字符串、Web 服务端点等）

【解决方案1】：

您似乎希望在多个环境（开发、暂存和发布）中自动部署和测试您的软件。

Release Management，它是 Visual Studio Team Services 和 Team Foundation Server（更新 2 及更高版本）中的一项服务，可帮助您实现此目标。

使用发布管理，您可以完全自动化地交付软件直至生产，也可以设置半自动化流程并进行审批和按需部署。在网站上查看更多信息：https://www.visualstudio.com/en-us/docs/release/overview

【讨论】：

谢谢。出于某种原因，我将构建定义与发布管理混淆了。因此，我们最终得到了大量的 RM 配置——就这样吧 :-) 然而，鉴于此，将 BD 保持在最低限度的需求变得更加紧迫。 BD 可以支持多个存储库吗？
在一个发布定义中，您可以将多个工件源链接到同一个发布定义：visualstudio.com/docs/release/author-release-definition/…。在 Git 构建定义中，您只能在团队项目中选择一个存储库