假设我们有一个android客户端和一个java api服务器 和代码提交到具有不同子文件夹的相同svn存储库
Svn版本1：[服务器版本1]
Svn Version 2：[Server version 1] [Client version 1]
Svn Version 3：[Server version 2] [Client version 1]
Svn Version 4：[Server version 2] [Client version 2]
Svn Version 5：[Server version 3] [Client version 2]
当开发人员检查版本5时，很容易设置buildserver并让maven使用最新的客户端版本2对服务器版本3代码进行集成测试。
但是我们有一大群用户使用版本1，我们当然需要在serverversion 3中为客户端版本1提供向后兼容性。
我的问题是maven / buildserver是否有为此类型集成测试构建的内容？
对于我的实例，我使用teamcity和maven来自动化我的集成测试。
=============================================== ======
在寻求Kozelka的推荐之后，以下是我将自动化测试的方式：
Svn布局
svn repository
client trunk
server trunk
released version
client release version 1
client release version 2
每次开发人员签入服务器主干时，teamcity build都会尝试对服务器代码执行“maven install”，并将其打包为war工件并安装到本地maven存储库。
然后将触发teamcity来检查客户端V1分支，在客户端版本1 pom中，它与最新的服务器工件有依赖关系，并且在集成之前使用最新的服务器工件启动jetty-使用客户端版本1 api视图测试和测试它。
同样适用于客户端版本2分支，并且对于每个支持的客户端版本，都需要在teamcity中构建一个单独的子项目，以确保最新的服务器可以向后兼容旧的api视图。
答案 0 :(得分：1)
我建议您为要支持的任何版本使用分支。您可以为需要维护的任何版本创建分支。
如果您的测试发现回归，您将提交对该特定分支的修复;在你提出的场景中，没有办法制作（和提交）修复，所以整个测试都没那么有用。
对于SVN，分支描述为here。 实际上，它只是将项目树复制到另一个位置（通常在/ branches /下），因为SVN没有单独的分支概念。其他版本控制系统的工作方式不同，但无论你使用哪种版本控制系统，分支似乎都是恕我直言的方式。
可能唯一的“缺点”是您需要在每个分支中单独维护测试。如果这是一个问题（=您有大量的测试），您可以通过将测试代码拆分为跨分支共享的单独模块来解决它。但通常您只需将提交从一个分支合并到另一个分支以达到相同或相似的功能;当分支中的代码及其测试偏差时，此选项很重要。
答案 1 :(得分：1)
如果两个部分位于SVN的不同子文件夹中，我认为您正在构建服务器中寻找两个不同的项目 - 以及单独部署它们的方法。如果您有自己喜欢的版本，请调用单元测试。
您面临的部分挑战是，您希望在那里部署时间决策与在“构建”时间完成大部分测试和部署逻辑之间的不匹配。如果你打破这两个概念，你可能会有更多的运气，
我认为在TC中，您可以通过另一种“构建”类型来执行此操作，该类型仅执行其他内容的部署。其他工具将部署视为单独的活动。