分离的开发/测试/生产环境下的Subversion仓库架构

Question

4

我被委托为dev/test/prod环境构建一个subversion系统，想知道是否有人有类似环境的经验或建议。

我们构建和配置了许多由脚本和复杂配置文件组成的系统，这些系统是第三方产品的组合。因此，重新构建配置文件和路径的布局是不可能的，因为我们无法控制第三方系统代码（即如果系统希望在特定位置放置配置文件，则必须在该位置）。

我们使用dev/test/prod方法论，但它比那更加复杂。每个阶段都有一个完整的物理环境。由于这个原因，每个阶段都需要进行一些修改，以使其在该环境中工作。所有开发必须在开发服务器上进行，测试在测试服务器上进行，然后我们有生产服务器。

在这种设置下，不可能将项目的副本签出到您自己的工作站上进行更改、测试，然后将其提交回去。这些内容只能在dev/test/prod服务器上运行（即与特定的主机名和IP范围相关联）。

因此，我认为有两个选择：

选项1

执行常规的trunk/branches/tags结构。然后，在构建的一部分中添加一个脚本，用于使所有更改特定于dev/test/prod环境。

例如，像往常一样将所有代码提交到主干，然后在满意后将其复制到发布标记。然后，在测试环境中，检出最新的标记。这包括一个“设置”脚本。

然后手动运行脚本（或通过SVN hook），它会检测到您正在测试服务器上，并相应地进行更改。

这种方式的问题是svn diffs等将显示对获取更改的文件的修改。优点是它（相当）简单。

选项2

将测试/生产分支和主干作为开发：

project
  trunk
  branches
    test
    prod
 tags
    v1.0
    v1.1

这个想法是开发服务器指向trunk。当我们对更改满意后，我们会创建一个新的标签。然后将其合并到branches/test上。这将已经包含使其在测试服务器上工作所需的更改。测试完成后，我们会在生产环境中做同样的事情。

据我所见，这种方法的优点是不需要花哨的钩子脚本，而且我们可以在开发/测试和开发/生产之间有更复杂的差异，SVN应该能够更好地通过合并来处理?

只是寻找一些输入、建议、经验等。我们与Subversion绑定，额外的工具不幸是不行的。

谢谢（抱歉内容有点长）！

- Matthew

虽然这是一篇旧帖，但可能仍有人在寻找类似的解决方案。我的建议是使用GIT而不是SVN。 - girish_vr

2个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jim T · Answer 1

说实话，我认为两种选择都是完全可行的。

然而，我略微倾向于您的第一个选择，原因是一旦您开始在某些分支之间出现“已知差异”，您必须开始使用脑力来解决“这是测试和生产之间的差异吗？”问题。

选择1，您始终都在同一个分支、同一段代码上工作和构建，因此您不会受到任何漂移的影响。每当有人进行更改时，他们可以立即（如果他们想）看到这将影响特定环境之前是否合并到它。

所以基本上这是一个保持简单的论点。这与根据客户品牌化软件的论点相同。两种方法都可行，但我倾向于选择1。

- nholloway4 · Answer 2

选项2似乎是一个不错的架构。我一直在寻找一个架构，并与其他开发人员讨论过。