选择适合我们部署需求的分支策略[关闭]

Question

背景

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

我们的情况

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

我的想法（到目前为止）

在我看来，我们真的只需要源代码控制中的两个分支：

1. 当前： 主干 - 从中​​进行部署
2. 下一步：当前迭代的开发分支

在新的迭代开始时，Current 将被分支（我们称该分支为 Next）。该迭代的所有开发都将提交给Next，同时，当前版本所需的任何错误修复都将提交给Current。在某一时刻，Next 将“完成”，因此，合并回 Current。

部署

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

注意事项

鉴于上述过程，将 Next 合并到 Current 将保证 Current 上的“代码冻结”，在此期间不会出现新错误修复可以发布给客户。此错误冻结将持续到 Current 被认为“足够好”以发布给客户，此时 Current 将被标记并且整个过程将重新开始。 p>

问题

1. 这种方法/思路合理吗？
2. 这种方法在哪里失败？
3. 有没有更好的方法来解决这个问题？

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

Answer 1

由于该软件只有一个版本，所以在发布给客户时更容易标记主干，并在主干上继续开发。

您不需要分支，除非您在开发时必须对软件进行修复。

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

Answer 2

我认为在这些情况下的主要指令是，您必须始终能够快速修复生产错误，而无需部署非生产代码。我觉得“在代码冻结期间不修复错误”警告会扼杀您灵活应对问题（不可避免地）出现的能力。

我们的流程与您的流程非常一致。我们通过这样的策略取得了巨大的成功：

Trunk 是树干。
Prod 是树干的分支。产品修订被标记，我们从这些标记进行部署。错误已修复并从此分支部署；这些修复将合并回主干。
下一个是一个或多个功能开发分支，它们在完成后会重新集成到主干中。

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

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

• 我们可以随时部署生产错误修复，而不必担心包含未烘焙的代码；
• 很容易将这些生产错误修复恢复到主线；
• 我们的主干本质上是一个合并日志并且保持相当干净。在任何时候，主干都可以合理地分支到 Prod；
• 我们在重新集成后删除了特征分支，这是一种宣泄和满足。

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