用于独立开发/测试/生产环境的 Subversion 存储库架构
我的任务是为开发/测试/生产环境建立一个颠覆系统，并且想知道是否有人有类似环境的经验或建议。
我们为第三方产品构建和配置许多由脚本和复杂配置文件组合而成的系统。因此，不可能重构配置文件和路径的布局，因为我们无法控制第 3 方系统代码（即，如果系统想要在某个位置有配置文件，那么它就必须在该位置）。
我们使用开发/测试/生产方法，但它比这更复杂一些。每个阶段都有一个完整的物理环境。因此，每个阶段都需要进行一些更改才能使其在该环境中运行。所有开发都必须在开发服务器上进行，在测试服务器上进行测试，然后我们就有了生产服务器。
通过这种设置，不可能将项目的副本检出到您自己的工作站上进行一些更改、测试它们，然后将它们提交回来。这些东西只能在开发/测试/生产服务器上工作（即与特定主机名和 IP 范围绑定）。
因此，在我看来，有 2 个选项：
选项 1
执行正常的主干/分支/标签结构。然后将脚本作为构建的一部分，使所有更改特定于开发/测试/生产环境。
例如，您将像往常一样将所有代码提交到主干，然后当您对此感到满意时，将其复制到发布标签。然后在测试环境中，您查看最新的标签。这包括一个“设置”脚本。
然后手动运行该脚本（或通过 SVN 挂钩），它会检测到您位于测试服务器上并进行相应的更改。
这种方式的问题是 svn diffs 等将显示对获得更改的文件的修改。优点是它（相当）简单。
选项 2
将测试/生产分支和主干作为开发：
project
trunk
branches
test
prod
tags
v1.0
v1.1
其想法是开发服务器指向trunk。当我们对更改感到满意时，我们会创建一个新标签。然后我们将其合并到branches/test。这已经进行了使其在测试服务器上运行所需的更改。然后，当测试完成时，我们对产品执行相同的操作。
从我看来，这种方法的优点是不需要花哨的钩子脚本，并且我们可以在 dev/test 和 dev/prod 之间有更复杂的差异，SVN 应该能够通过合并更好地处理？
只是寻找一些意见、建议、经验等。我们与 Subversion 紧密相连，不幸的是，额外的工具是不行的。
谢谢（抱歉太长了）！
I've been tasked to build up a subversion system for dev/test/prod environments, and was wondering if anyone has any experience with a similar environment or suggestions.
We build and configure a number of systems that are a combination of scripts and complex configuration files for 3rd party products. Due to this, it is impossible to restructure the layout the config files and paths because we don't control the 3rd party system code (i.e. if the system wants a config file in a certain place, that's where it has to be).
We work with a dev/test/prod methodology, but it is a little more complex than that. There is a complete physical environment for each stage. Due to this, each stage needs some alterations that need to occur to make it work in that environment. All development must occur on the development server, testing on the test server then we have the production servers.
With this setup, it is impossible to check out a copy of a project to your own workstation make some changes , test them, and the commit them back. This stuff will only work on a dev/test/prod server (i.e. things are tied to specific hostnames and IP ranges).
So, as I see it there are 2 options:
Option 1
Do the normal trunk/branches/tags structure. Then have a script as part of the build that would make all the changes specific for the dev/test/prod environments.
For example, you'd commit all code to the trunk as usual, then when you're happy with it you copy it over to a release tag. Then in the test environment, you check out the latest tag. This includes a 'setup' script.
Then the script is run manually (or via SVN hook) and it would detect that you're on the test server and make the changes accordingly.
Problem with this way is that svn diffs etc. are going to show modifications to the files that get the alterations. The advantage is that it's (fairly) simple.
Option 2
Make test/prod branches and trunk as the development:
project
trunk
branches
test
prod
tags
v1.0
v1.1
The idea being that the dev server points to trunk. When we're happy with the changes we make a new tag. Then we merge it on to branches/test. This will already have the changes necessary to make it work on the test server. We then do the same for prod when testing is complete.
From what I can see, the advantage of this approach is that there is no need for fancy hook scripts, and we can have more complex differences between dev/test and dev/prod that SVN should be able to handle better via merging?
Just looking for some input, suggestions, experience etc. We are tied to Subversion and extra tools are unfortunately a no-go.
Thanks (sorry about the length)!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
老实说，我认为这两种选择都是完全可行的。
然而，我稍微更喜欢你的第一个选择，原因是一旦你开始了解某些分支之间的“已知差异”，你就必须开始使用脑力来计算出“这是测试和产品之间应该存在的差异吗？”
使用选项 1，您绝对可以始终工作并享受生活。使用相同的分支、相同的代码进行构建，因此您不会遇到任何这种偏差。任何时候任何人做出更改，他们都可以立即（如果他们愿意）看到这是否会影响特定环境，然后再合并到特定环境。
所以这基本上是一个让事情变得简单的论点。如果您根据客户来打造软件品牌，这也是同样的道理。两种方法都可行，但我倾向于选项 1。
Honestly, I think either option is perfectly viable.
However, I slightly prefere your first choice, reason being that once you start getting 'known differences' between certain branches you have to start using brain power to work out "is this a difference between test and prod that's supposed to be there?"
With option 1, you're always, definitely, working & building out of the same branch, same code, so you just wont get any of this drift. Anytime anyone makes a change, they can see immediately (if they want to), wether this will impact specific environments before they merge to it.
So it's basically an argument to keep things simple. It's the same argument if you brand your software according to your customer. Either method is viable, but I'm leaning towards option 1.
选项 2 似乎是一个不错的架构。一直在仔细寻找一个以及与其他开发人员讨论
Option 2 seems like a good architecture. Have been perusing looking for one as well and discussing with other developers as well