TFS和存储二进制文件

Question

我们的项目组存储了我们在SVN存储库中工作的项目的二进制文件超过一年，最终我们的存储库失去控制，因为每个二进制文件都是一个点，所以SVN repo的备份变得不可能。签到的大概是20 MB。

现在我们切换到TFS，我们不负责支持存储库，我们的IT tream会处理它，我们有更多的网络和存储容量用于备份，但我们想要决定如何处理二进制文件。据我所知，TFS存储增量和二进制文件，但增量将是巨大的，但我们可能最终达到我们的磁盘空间配额一天，所以我想从一开始就做好计划，我不想得到陷入困境时，解决问题为时已晚。

我不希望在源代码控制中保留构建，但是我们的项目组坚持要保留每个二进制文件的副本以重现我们在生产系统中看到的问题，我无法让他们从TFS获取源代码，构建它并创建二进制文件，因为根据它们并不简单。

TFS是否提供更好的构建版本控制方法？如果有人可以分享一些见解，我真的很感激。

Answer 1

作为一般规则，您不应该在TFS中存储构建输出。有时您可能希望存储许多应用程序使用的公共库的二进制文件，但是nuget之类的工具可以解决这个问题。

构建输出具有其生命周期的几个阶段，每个阶段应存储在单独的位置。 e.g。

构建输出：构建代码时（由TFS / Jenkins / Hudson等），输出存储在放置位置。这个存储应该被认为是易失性的，因为你将产生大量的构建，其中许多将被丢弃。

已传递给测试人员的构建：这些是已通过一些非常基本的QA的构建，例如它编译，静态代码分析工具很开心，单元测试通过。一旦构建被认为足够好以便进行测试，它应该从放置位置移动到另一个区域。这可能是网络共享（非生产，因为可以重现构建）可能有许多构建在项目的生命周期中得到提升，并且您将需要跟踪测试人员在每个环境中使用的版本。

已通过测试且正在投入使用的构建版本：您的测试团队认为构建质量足够高，可以发布。作为上线过程的一部分，您应该通过测试签署已构建的构建并将其存储在第3个位置。在ITIL中说这是Definitive Media Library。这可以是一个简单的文件共享，但它应该被视为“生产”并具有与任何其他生产系统相同的备份和弹性标准。

DML是存储生产中的二进制文件的位置（以及相关的配置项，如安装说明，符号文件等）。生成构建的工具也应在TFS中标记源，以便您可以工作用什么代码来生成二进制文件。您的分支策略也有助于将二进制文件连接到代码。

拥有一个“类似”的环境也是一个好主意，这应该与您的常规开发和测试环境分开。顾名思义它只包含已发布到生产中的代码。这使您可以快速重现生产中的错误

Answer 2

可以帮助您的两种方法：

1. 使用Team Foundation Build System。其中一个优点是您可以为完成的构建设置保留期。例如，您可以命令TFS存储10个最新的成功版本，以及最新的两个版本。您还可以告诉TFS无限期地存储某些构建（例如“生产构建”/最终版本）。如果需要，这些二进制文件夹当然也可以在外部备份。

2. 为二进制文件使用不同的集合，使用另一个（较不频繁的）备份计划。 TFS需要备份整个集合，但通过将不会像源一样频繁更改的数据分开，您可以降低备份成本。这当然取决于备份二进制文件所需的频率。

Answer 3

您可能希望研究在TFS中创建构建定义，以便为项目组提供一个简单的“一键式”推送，以从特定分支中获取源代码，然后构建它并将其放到某个位置。这样他们就可以得到他们的二进制文件了，而且你不需要控制它们。

如果您正在使用分支策略来创建Release或RTM分支，那么您可以将构建定义指向这些分支，并且可以从TFS门户或Visual Studio中手动触发它们。