5

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

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

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

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

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

  1. 通过仅从主干合并到测试分支以及从测试分支合并到生产分支，我可以完全控制哪些修改流向哪些环境
  2. 只需查看 Subversion 中相应分支的日志，我就可以轻松查看每个环境中正在执行的代码

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

4

2 回答 2

7

有没有人有过类似的解决方案的经验？

是的 ：-）

我是否遗漏了任何潜在的陷阱或疏忽？

您将面临这样一个问题，即随着时间的推移，测试和发布分支将偏离开发环境，因为您很可能不会合并来自主干的所有更改。然后，开发人员将在稍微不同的环境中工作，并且您会因为保持分支同步而浪费大量时间。这被称为合并狂热反模式。

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

对每个版本重复该过程。这样，您将限制合并的数量，并让人们致力于始终处于前沿的事物。

我希望这些方面对您的决定有所帮助。该链接还显示了许多其他反模式。阅读他们所有人，也许你会认识到一些经验教训，并会得到一些提示来更好地解决它。

于 2010-09-07T21:53:27.320 回答
2

我们使用相同的布局没有任何问题。确保使用最新的 svn 版本。由于缺少合并跟踪，不应使用 1.5 之前的版本。

与来自 atlassian 的 jira 等错误跟踪工具（我不是赞助商）结合使用时，您的设置会变得更加透明。

于 2010-09-07T21:39:07.443 回答