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