用于单独的开发/测试/生产环境的 Subversion 存储库架构

Question

我的任务是为开发/测试/生产环境构建一个颠覆系统，想知道是否有人对类似环境有任何经验或建议。

我们为第 3 方产品构建和配置了许多由脚本和复杂配置文件组合而成的系统。因此，由于我们无法控制第 3 方系统代码（即，如果系统想要在某个地方有一个配置文件，那它就必须在那个地方），因此无法重构配置文件和路径的布局。

我们使用开发/测试/产品方法，但它比这更复杂一些。每个阶段都有一个完整的物理环境。因此，每个阶段都需要进行一些更改才能使其在该环境中工作。所有的开发都必须在开发服务器上进行，在测试服务器上进行测试，然后我们就有了生产服务器。

使用此设置，不可能将项目的副本签出到您自己的工作站进行一些更改、测试它们，然后将它们提交回来。这些东西只能在 dev/test/prod 服务器上工作（即，事物与特定的主机名和 IP 范围相关联）。

所以，在我看来，有两种选择：

选项 1

做正常的主干/分支/标签结构。然后有一个脚本作为构建的一部分，它将针对 dev/test/prod 环境进行所有更改。

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

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

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

选项 2

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

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

这个想法是开发服务器指向trunk。当我们对更改感到满意时，我们会制作一个新标签。然后我们将其合并到branches/test。这已经具有使其在测试服务器上工作所需的更改。测试完成后，我们对 prod 执行相同操作。

据我所知，这种方法的优点是不需要花哨的钩子脚本，我们可以在 dev/test 和 dev/prod 之间有更复杂的差异，SVN 应该能够通过合并更好地处理?

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

谢谢（对篇幅感到抱歉）！

Answer 1

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

但是，我稍微偏爱您的第一选择，原因是一旦您开始了解某些分支之间的“已知差异”，您就必须开始使用脑力来解决“这是应该存在的 test 和 prod 之间的差异吗？ ？”

使用选项 1，您肯定总是在相同的分支、相同的代码中工作和构建，因此您不会有任何这种偏差。任何人进行更改时，他们都可以立即看到（如果他们愿意的话），这是否会在他们合并之前影响特定环境。

所以它基本上是一个让事情保持简单的论点。如果您根据客户为您的软件打上商标，这也是同样的论点。两种方法都是可行的，但我倾向于选项 1。

Answer 2

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