我的任务是为dev / test / prod环境构建一个subversion系统，并且想知道是否有人有类似环境或建议的经验。
我们构建并配置了许多系统，这些系统是第三方产品的脚本和复杂配置文件的组合。因此，不可能重新配置配置文件和路径的布局，因为我们不控制第三方系统代码（即，如果系统需要某个位置的配置文件，那就是它必须在哪里）。 / p>
我们使用dev / test / prod方法，但它比这复杂一点。每个阶段都有完整的物理环境。因此，每个阶段都需要进行一些改动才能使其在该环境中发挥作用。所有开发必须在开发服务器上进行，在测试服务器上进行测试，然后我们就有生产服务器。
使用此设置，无法检查项目的副本到您自己的工作站进行一些更改，测试它们并将它们提交回来。这些东西只能在dev / test / prod服务器上运行（即事物与特定的主机名和IP范围相关联。）
所以，我认为它有两个选择：
选项1
执行正常的trunk / branches / tags结构。然后将脚本作为构建的一部分，使所有更改特定于dev / test / prod环境。
例如，您像往常一样将所有代码提交到主干，然后当您对它感到满意时，将其复制到发布标记。然后在测试环境中，查看最新的标签。这包括“设置”脚本。
然后手动（或通过SVN挂钩）运行脚本，它会检测到您在测试服务器上并相应地进行更改。
这种方式的问题是svn diffs等将显示对获得更改的文件的修改。优点是它（相当）简单。
选项2
将test / prod分支和主干作为开发：
project
trunk
branches
test
prod
tags
v1.0
v1.1
这个想法是开发服务器指向trunk。当我们对变化感到满意时，我们会制作新标签。然后我们将其合并到branches/test。这将具有使其在测试服务器上运行所必需的更改。然后，当测试完成时，我们会为prod做同样的事情。
从我所看到的，这种方法的优点是不需要花哨的钩子脚本，我们可以在dev / test和dev / prod之间有更复杂的差异，SVN应该能够通过合并更好地处理？
只是寻找一些输入，建议，经验等等。我们与Subversion绑定，不幸的是额外的工具是禁止的。
谢谢（抱歉长度）！
答案 0 :(得分：0)
老实说，我认为任何一种选择都是完全可行的。
然而，我稍微倾向于你的第一选择，原因是一旦你开始在某些分支之间获得“已知差异”，你必须开始使用脑力来解决“这是测试和产品之间应该存在的差异吗？ ？“
对于选项1，你总是，绝对，工作和建立在同一个分支，相同的代码，所以你不会得到任何这种漂移。任何人在任何时候进行更改，他们都可以立即看到（如果他们想要的话），这会影响特定环境，然后再合并到它。
所以这基本上是一个让事情变得简单的论据。如果您根据客户对软件进行品牌化，那就是同样的论点。这两种方法都是可行的，但我倾向于选项1。
答案 1 :(得分：0)
选项2似乎是一个很好的架构。一直在寻找一个并与其他开发人员讨论