2

我们公司（内部项目）使用版本控制（TFS，现为 2015 年）来简单地保留已发布代码的审计跟踪 - 我引入了分支和合并的使用，它完全改变了我们看待开发管道中瓶颈的方式和普遍受到好评，但现在我正在寻找下一步。

我们的代码由一个大型软件和其他几个附带的业务应用程序组成。

我们有四个始终保持不变的环境，我们的“管道”就是这样。

  • 开发人员在本地工作。
  • 将代码推送到“开发”环境（因此我们都可以查看代码，了解它在环境中的集成情况等）
  • 当测试准备好时，我们推送到“测试”——这是已被批准向上移动的代码，因此环境比“开发”稳定得多。
  • 接下来，我们将它传递给 UAT 服务器，它本质上是对实时服务器的模仿，以尽可能稳定并代表实时发布。批准移到这里的代码并不常见。
  • 最后，生产环境。

现在我只是简单地为每个环境建立一个分支，以便于比较，让人们快速获取源代码和诸如此类的东西，并查看代码库在链上的进展。

主要 -> 阶段 -> 测试 -> 开发

这是一条直线，我们可以简单地查看 MAIN 分支的历史，以查看所有不同的发布版本。

我们从 dev 分支分裂到本地分支，任何修补程序都直接来自 UAT 分支。

这对我们有用——但它在程序程序可以工作的意义上是有效的——它可能不是最有效的方法。我只是很好奇是否有更好的方法可以做到这一点，在网上阅读了大量内容后，我觉得人们不会按环境划分分支，但我真的不明白如何更好地工作？尽管合并四次以发布一些代码很痛苦（尽管大多数时候它是一个相当慢的管道，但我们每周发布一次）。

非常感谢任何帮助。

4

2 回答 2

3

当提到分支策略越复杂，维护的开销就越大时，您是正确的。

但是，如果情况需要，也不会逃跑。如果您还没有阅读ALM rangers 的 TFS分支策略文档，请查看。它应该可以帮助你。

我认为您遵循的策略不是线性分支，而是下图中的策略。在更复杂的企业软件中，分支策略归结为这一点。 最复杂的分支策略

于 2016-03-21T05:51:36.210 回答
2

正如您在上面正确提到的（尤其是合并的数量），我认为为每个环境维护不同的分支是很多开销。最简单的分支策略如下所示（类似于我们使用的）：

               Main
             |     |
             |     |
            DEV  Release

开发将在 DEV 分支中进行，一旦为 UAT 做好准备，我们将其合并到 MAIN 中，然后创建一个 Release 分支。此时您可以使用 DEV 分支进行下一个版本开发，当前版本的所有错误修复都将在发布分支中进行。Release 分支也将用于 PROD 部署。

至于这是否适合您，将取决于您的具体需求，但我参与的项目中有 80% 使用上述分支策略。

于 2016-03-21T02:58:43.127 回答