在TFS中进行年度发布计划？

Question

问题：根据下面提供的信息创建用于开发和发布的分支的最佳实践是什么？

背景：I在一个小型开发团队(2.25前端，2个后端)工作，我们有一个年度发布计划。我们的环境不允许(不允许)在年中使用补丁或服务包，但是每隔一段时间，如果我们的用户环境发生变化，我们就会发布一个“重新编译”版本，并附带一些bug修复(在当前稳定版本上)。

目前，我们在主线上完成了所有的开发工作，然后为代码冻结创建了一个分支(到目前为止已经创建了5个分支)，并做了一些小的bug修复和大量的测试。一旦版本被发送到分层和部署，我们将这些错误修复合并回主线，在那里我们继续为明年的发布开发新的功能。分支将永远留在我们的存储库中。

TFS做分支的方式是在源代码管理中有一个新的“文件夹”，并且它开始变得有点混乱。

的想法：也许我们这样做是对的，但感觉再过几年，就会有大量的树枝永远不会被碰触……似乎永远都不会。也许可以创建一个“稳定版本”行，在其上贴上每一个新版本的标签，然后如果我们需要回去做一个年中发行，那么它可以从这一行恢复。

Answer 1

management.

• Your

• 将你的环境升级到2010年-- TFS 2010分支的优势要大得多，包括当你有一个发布版本的时候，你的想法听起来是正确的--当你有一个发布版本的时候，你只需要修复它。

• ，你只需要忍受版本的积累。这是有道理的--直到你完全退休(而且“永远”在这里不是真的，我敢打赌，7-8年后你杀了一个旧版本)，没有别的办法了。

Answer 2

我工作过的几个地方会这样处理：

• Devs从不直接接触“主”分支，它始终代表生产中的
• --在全年的所有更改中都使用了一个“维护”分支。
• 在年底时，在所有更改准备就绪后，适当地标记所有内容，并将维护分支合并回主线中。
• 正在维护分支中进行持续的更改。
• Rinse并根据需要重复。

好处是你只有两个分支。这使得一些与SCM相关的任务更容易处理，因为您不必一直处理更改文件夹名称等问题。