测试不同客户端和服务器版本的最佳Git策略

测试不同客户端和服务器版本的最佳Git策略,git,testing,maven,versioning,Git,Testing,Maven,Versioning,我希望能够为Java客户机/服务器运行集成测试(使用嵌入式jetty)。此外,我希望能够在集成测试期间混合和匹配不同的服务器和客户端源代码版本 我想知道最好的git或maven版本策略是什么: 对于客户端和服务器使用相同的git存储库,很难签出不同服务器版本的代码,并根据不同客户端版本的代码进行测试 使用单独的git存储库(第一个存储库带有客户端src和集成测试,第二个存储库带有服务器src)-还需要签出两个存储库来运行集成测试,并假设它们之间的相对路径 仅针对maven版本的服务器WAR测试客

我希望能够为Java客户机/服务器运行集成测试(使用嵌入式jetty)。此外,我希望能够在集成测试期间混合和匹配不同的服务器和客户端源代码版本

我想知道最好的git或maven版本策略是什么:

  • 对于客户端和服务器使用相同的git存储库,很难签出不同服务器版本的代码,并根据不同客户端版本的代码进行测试

  • 使用单独的git存储库(第一个存储库带有客户端src和集成测试,第二个存储库带有服务器src)-还需要签出两个存储库来运行集成测试,并假设它们之间的相对路径

  • 仅针对maven版本的服务器WAR测试客户机src代码,可能会导致开发人员在针对与签出的服务器源代码不匹配的服务器WAR运行测试时出现诚实的错误


  • 我将指出第三个挑战:集成测试可能有bug,因此您可能希望独立控制测试版本

    我已经使用git的子模块功能来协调多个存储库。创建一个新的存储库,其中包含对客户端repo和服务器repo的引用。您也可以在此父repo中放置基本测试驱动程序

    当新开发人员加入团队时,他们可以克隆此父repo,然后运行
    git submodule update--init
    克隆客户机和服务器子模块。这样,他们就可以像其他人一样设置任何相对路径

    但是,我不喜欢让客户机repo假设服务器位于
    。/server/
    。所以我处理这个问题的方法是让父repo将任何需要的路径传递给子模块。例如,您可以在运行的父回购中有一个
    test.sh

    make -C client SERVER_PATH=$(pwd)/server test
    
    在您的情况下,您还可以将所有测试代码放在父repo中。然后它可以安全地假定到子模块的相对路径


    这种安排的一个有趣的附带好处是:您可以创建git提交,记录特定的版本组合,因为在子模块中签出的版本是在您在父repo中提交时记录的。您可以使用它为通过测试的版本组合创建一个分支或一组标记。

    我建议保持过程简单,因为您已经有了足够的变量,而不会引入潜在的git管理问题。为此,我将避免使用子模块。相反,我会给开发人员提供分支/标记的清晰配对,以便在测试矩阵中测试客户机和服务器repo

    使用标签,以便将来可以更轻松地重用和重复矩阵中的相同测试,特别是在第一轮修复bug之后


    简言之,我推荐您的解决方案2。相对路径假设比子模块引入的潜在混淆更可取。

    您知道git bisect命令吗?如何使用git bisect命令运行特定的服务器版本和特定的客户端版本?git子模块如何与git新手公平?我担心这会给开发者增加太多的复杂性。这是针对90%的开发人员的一次性设置(他们只是想假设每个子回购都是一个独立的回购),还是他们应该知道子模块?我与其他四名开发人员一起完成了这项工作,此后又有许多其他开发人员来了又走。在大多数情况下,这是一次性的设置:一旦他们运行了
    git子模块更新--init
    ,他们就不必再考虑它了。必须使用我在上面构建的构建系统的开发人员遇到了更多的麻烦,但您不必走那么远。:-)(我已经做了一个题为“为什么你不应该让我设计你的构建系统”的演讲,但是收件人还是复制了我的设计…)你是如何克服子模块是通过提交而不是分支名称跟踪的问题的?运行“git submodule update”命令的流程是什么?至少对我们来说,通过提交跟踪子模块是一项功能,因为它准确地记录了我们一起测试的版本。但是,没有人喜欢子模块更新导致的“分离头”状态。我编写了一个脚本,为HEAD创建一个临时分支,在master、checkout master上重新设置它的基础,快进到临时分支,然后删除临时分支。这涵盖了我们遇到的最常见的事故,但即使是这样的事故也不经常发生。