我被委托为dev/test/prod环境构建一个subversion系统,想知道是否有人有类似环境的经验或建议。
我们构建和配置了许多由脚本和复杂配置文件组成的系统,这些系统是第三方产品的组合。因此,重新构建配置文件和路径的布局是不可能的,因为我们无法控制第三方系统代码(即如果系统希望在特定位置放置配置文件,则必须在该位置)。
我们使用dev/test/prod方法论,但它比那更加复杂。每个阶段都有一个完整的物理环境。由于这个原因,每个阶段都需要进行一些修改,以使其在该环境中工作。所有开发必须在开发服务器上进行,测试在测试服务器上进行,然后我们有生产服务器。
在这种设置下,不可能将项目的副本签出到您自己的工作站上进行更改、测试,然后将其提交回去。这些内容只能在dev/test/prod服务器上运行(即与特定的主机名和IP范围相关联)。
因此,我认为有两个选择:
选项1
执行常规的trunk/branches/tags结构。然后,在构建的一部分中添加一个脚本,用于使所有更改特定于dev/test/prod环境。
例如,像往常一样将所有代码提交到主干,然后在满意后将其复制到发布标记。然后,在测试环境中,检出最新的标记。这包括一个“设置”脚本。
然后手动运行脚本(或通过SVN hook),它会检测到您正在测试服务器上,并相应地进行更改。
这种方式的问题是svn diffs等将显示对获取更改的文件的修改。优点是它(相当)简单。
选项2
将测试/生产分支和主干作为开发:
这个想法是开发服务器指向
据我所见,这种方法的优点是不需要花哨的钩子脚本,而且我们可以在开发/测试和开发/生产之间有更复杂的差异,SVN应该能够更好地通过合并来处理?
只是寻找一些输入、建议、经验等。我们与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绑定,额外的工具不幸是不行的。
谢谢(抱歉内容有点长)!