.net - 颠覆 : Branch per Environment?

Question

我目前正在 .NET 中开展一个项目，该项目由多个逻辑层和多个前端组成。这是我们 SVN 结构的粗略表示:

trunk
---doc
---lib
---src
------console
---------console.vbproj
------domain
---------domain.vbproj
------...
------web
---------web.vbproj
---.sln

我们所有的日常开发都发生在主干中 - 这是所有开发人员结帐/提交的地方。

我正在寻找一种在环境(测试和生产)之间干净且轻松地部署的方法。

我的想法是从主干创建两个分支，测试和生产 - 解决方案和所有。我为自己辩解，原因如下:

我可以完全控制哪些修改流向哪些环境，只需从主干合并到测试分支，从测试分支合并到生产分支

在Subversion

中只需查看对应分支的日志，就可以很容易的看出每个环境中正在执行什么代码

有没有人有过与此类似的解决方案的经验？是否有任何我遗漏的潜在陷阱或疏忽？

Answer 1

Has anyone had any experience with a solution similar to this?

是的 :-)

Are there any potential pitfalls or oversights that I am missing?

您将面临这样的问题，随着时间的推移，测试和发布分支将远离开发环境，因为您很可能不会合并主干中的每个更改。然后，开发人员将在稍微不同的环境中工作，保持分支同步会浪费很多时间。这被称为 merge-mania anti-pattern .

我宁愿建议在您实现所有功能后，从主干为每个计划发布创建一个发布分支。在你分支的时候，两者都是平等的。然后让一个团队在发布分支上进行稳定和测试。开发在主干上并行进行。一旦你的版本被完善，将修复合并回主干。

对每个版本重复该过程。通过这种方式，您将限制合并的数量，并让人们从事始终处于前沿的工作。

我希望这些方面可以帮助您做出决定。该链接还显示了许多其他反模式。通读一遍，也许你会认识到一些经验教训，并会得到一些提示来更好地解决它。