2

背景

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

我们的情况

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

我想出什么（到目前为止）

如我所见，我们实际上只需要源代码控制中的两个分支：

  1. 当前： trunk - 部署发生的地方
  2. Next：当前迭代的开发分支

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

部署

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

注意事项

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

问题

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

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

4

2 回答 2

2

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

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

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

于 2012-12-20T18:40:17.763 回答
1

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

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

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

当我们准备好发货时，我们会制作一个新的Prod并重新开始循环。

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

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

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

于 2012-12-20T19:49:18.877 回答