选择分支策略以满足我们的部署需求

Question

背景

所以，我花了上个月的大部分时间使用MSDeploy，SSDT和TeamCity自动化我们的web + db部署。唯一的问题是，出于演示目的，我只在我们的主干分支机构工作。毋庸置疑，当您考虑需要进行并行开发工作（由SVN中的分支隔离）时，这种方法很快就会失败。这就是我被困住的地方，希望能找到一些帮助。

我们的情况

• 我们从不必须支持我们软件的多个并发版本
• 当前版本的客户始终

我想出了什么（迄今为止）

正如我所看到的，我们在源代码管理中只需要两个分支：

1. 当前：主干 - 发生部署
2. 下一步：当前迭代的开发分支

在新迭代开始时，当前将被分支（让我们调用该分支下一步）。该迭代的所有开发都将提交到 Next ，同时，当前版本所需的任何错误修复都将提交到当前。在某一时刻，下一步将“完成”，从而合并回当前。

部署

就部署而言， Next 永远不会部署到任何环境。但是，当前将由TeamCity定期（每次提交，每晚等）自动打包/部署到内部环境。在某些时候，其中一个软件包将被视为“足够好”，因此，按下部署流（通过分段，生产）。

注意事项

鉴于上述过程，将下一步合并到当前将保证当前上的“代码冻结”，在此期间没有新错误修复程序可以发布给客户端。此错误冻结将一直持续到当前被认为“足够好”才能发布给客户端，此时当前将被标记，整个过程将重新开始。

问题

1. 这种方法/思路是否合理？
2. 这种方法在哪里落下来？
3. 有更好的方法可以解决这个问题吗？

非常感谢任何见解/文档。

Answer 1

由于该软件只有一个版本，因此当您向客户发布时标记主干并在主干上继续开发会更容易。

您不需要分支，除非您在开发过程中必须修复软件。

您必须决定分支开发是否更适合您和您的开发组，而不是分支修复生产错误。

Answer 2

我认为这些场景中的主要指令是，您必须始终能够快速修复生产错误，而无需部署非生产代码。我觉得“在Code Freeze期间没有错误修复”的警告会使你的灵活性和对问题的反应成为可能，因为它们（不可避免地）会出现。

我们的流程与您的流程非常接近。我们通过这样的策略取得了很大的成功：

Trunk 是主干。
Prod 从树干分支出来。产品标记被标记，我们从这些标记进行部署。从这个分支修复和部署错误;这些修复程序合并回主干 下一步是一个或多个功能开发分支，它们在完成后重新集成到主干中。

当我们准备发货时，我们会制作一个新的产品，然后重复开始。

我们喜欢这个模型，因为：

• 我们可以随时部署生产错误修正，而无需担心合并未经烘焙的代码;
• 很容易将这些生产错误修复回到主线上;
• 我们的主干基本上是一个合并的日志，并保持相当干净。在任何时候，行李箱都可以合理地分支到Prod;
• 我们删除重新整合后的功能分支，这是一种宣泄和令人满意的功能。

我们的管理层喜欢这种模式，因为我们可以快速响应问题并且回归的可能性很低。