TFS 和存储二进制文件

Question

我们的项目组在 SVN 存储库中存储了我们正在处理的项目的二进制文件一年多，最终我们的存储库失去了控制，一度无法备份 SVN 存储库，因为签入的每个二进制文件都是大约 20 MB。

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

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

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

Answer 1

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

构建输出有其生命周期的几个阶段，每个阶段都应存储在单独的位置。例如

构建输出：当构建代码（通过 TFS/Jenkins/Hudson 等）时，输出存储在放置位置。此存储应被视为易变的，因为您将生成大量构建，其中许多将被丢弃。

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

已通过测试并投入生产的构建：您的测试团队认为构建的质量足以交付。作为上线过程的一部分，您应该获取已通过测试签署的构建并将其存储在第三个位置。在ITIL 中，这是一个权威媒体库。这可以是一个简单的文件共享，但它应该被视为“生产”并且具有与任何其他生产系统相同的备份和弹性标准。

DML 是您存储生产中的二进制文件（以及相关的配置项，例如安装说明、符号文件等）的地方。生成构建的工具也应该在 TFS 中标记源代码，以便您可以计算出哪些代码用于生成二进制文件。您的分支策略还有助于将二进制文件连接到代码。

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