我们的项目组将我们在 SVN 存储库中工作的项目的二进制文件存储了一年多，最终我们的存储库失控，备份 SVN 存储库一度变得不可能，因为每个二进制文件都是签入大约 20 MB。
现在我们切换到 TFS，我们不负责备份存储库，由我们的 IT 团队负责处理，因此我们有更多的网络和存储容量用于备份，但我们想决定如何处理二进制文件.据我所知，TFS 存储增量和二进制文件，但增量会很大，但有一天我们可能最终会达到磁盘空间配额，所以我想从一开始就更好地计划事情，我不想得到当解决问题为时已晚时陷入了糟糕的境地。
我不希望在源代码控制中保留构建，但我们的项目组坚持保留每个二进制文件的副本以重现我们在生产系统中看到的问题，我无法让他们从 TFS 获取源代码，构建它并创建二进制文件，因为根据它们并不简单。
TFS 是否提供更好的构建版本控制方法？如果有人能分享一些见解，我将不胜感激。
【问题讨论】：
作为一般规则，您不应将构建输出存储在 TFS 中。有时您可能希望存储许多应用程序使用的通用库的二进制文件，但 nuget 等工具可以解决这个问题。
构建输出在其生命周期中有几个阶段，每个阶段都应存储在单独的位置。例如
构建输出： 构建代码时（通过 TFS / Jenkins / Hudson 等），输出存储在放置位置。此存储应被视为易失性，因为您将生成大量构建，其中许多将被丢弃。
已传递给测试人员的构建：这些构建已通过一些非常基本的 QA，例如它编译，静态代码分析工具很高兴，单元测试通过。一旦构建被认为足以进行测试，就应该将其从放置位置移动到另一个区域。这可能是网络共享（非生产，因为可以复制构建）可能有许多构建在项目的生命周期内得到提升，您需要跟踪测试人员在每个环境中使用的版本。
已通过测试并投入生产的版本：您的测试团队认为该版本的质量足以交付。作为上线过程的一部分，您应该获取已通过测试签署的构建并将其存储在第三个位置。在ITIL 发言中，这是Definitive Media Library。这可以是一个简单的文件共享，但它应该被视为“生产”并且具有与任何其他生产系统相同的备份和弹性标准。
DML 是您存储生产中的二进制文件（以及相关的配置项，如安装说明、符号文件等）的地方。生成构建的工具还应该在 TFS 中标记源，以便您可以工作找出用于生成二进制文件的代码。您的分支策略还有助于将二进制文件连接到代码。
拥有“实时”环境也是一个好主意，它应该与您的常规开发和测试环境分开。顾名思义，它仅包含已发布到生产环境的代码。这使您能够快速重现生产中的错误
【讨论】：
两种可能对您有所帮助的方法：
使用 Team Foundation 构建系统。优点之一是您可以为已完成的构建设置保留期。例如，您可以命令 TFS 存储 10 个最新成功的构建和两个最新失败的构建。您还可以告诉 TFS 无限期地存储某些构建（例如“生产构建”/最终版本）。如果需要，这些二进制文件夹当然也可以在外部备份。
为您的二进制文件使用不同的集合，并使用另一个（不那么频繁的）备份计划。 TFS 需要备份整个集合，但通过分离不会像源一样频繁更改的数据，您可以降低备份成本。这当然取决于备份二进制文件所需的频率。
【讨论】：
您可能希望考虑在 TFS 中创建构建定义，以便为您的项目组提供一个简单的“一键式”按钮，以便从特定分支获取源代码，然后构建它并将其放置到某个位置。这样他们就可以拥有自己的二进制文件，而您不必对它们进行源代码控制。
如果您使用分支策略，在将某些内容推送到生产环境时创建 Release 或 RTM 分支，那么您可以将构建定义指向这些分支，它们可以从 TFS 门户或 Visual Studio 中手动触发它们。
【讨论】：