我们的项目组将我们正在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中手动触发它们。