代码之家  ›  专栏  ›  技术社区  ›  ru3sch

Git流和多种功能等待QA

  •  5
  • ru3sch  · 技术社区  · 10 年前

    在过去的几个月里,我们一直在松散地跟踪git流,但在漫长的QA等待中遇到了问题。

    以下是我们的流程:

    • 开发人员在功能分支上进行本地开发
    • 当团队认为该功能已准备就绪时,将其合并到开发中,并推送到开发服务器(Codeship&rsync)
    • 客户端批准功能
    • 功能合并到主功能中,推到prod

    不幸的是,客户有时可能需要数周的时间来批准一项功能。这可能是由于积压、内容创建、员工流动等原因。

    然而,在此期间,一个新功能可能已经被合并到dev中,并被推送到dev服务器以获得批准。假设第二个功能获得批准,需要尽快部署(当然)。如果没有第一个功能,我怎么才能从开发中删除第二个功能?

    3 回复  |  直到 10 年前
        1
  •  4
  •   Community CDub    8 年前

    我怎么才能把第二个功能去掉 dev 没有带来第一个功能?

    你不会的。
    但有一次 开发 已合并到 master , you can revert the 1st feature commits 从…起 主人 ,以便记录第一个功能尚未获得批准。

    这比 cherry-picking the commits 从第二个特性,因为它将复制来自 开发 主人 ,并使将来的合并更加复杂。


    如果经常重复,则工作流不适合当前的开发过程。

    如果:

    • 你有一个 integration 分支,在该分支中合并任何要批准的功能(在开发服务器上)。
    • 开发 将进行更新 只有 具有 经核准的 功能分支中的功能(在开发服务器上)。

    换句话说,您将合并要素分支两次:

    • 一次,一次 集成 正式的客户审查和批准功能
    • 一次,一次 开发 ,进行第二次(而且更快)客户端检查,以查看该功能是否仍按预期工作(因为它与集成中的代码库不在同一代码库中合并)

    从…起 开发 ,您将恢复正常的发布管理过程( prod )

        2
  •  1
  •   vribeiro    5 年前

    我们的环境中也存在同样的问题,客户需要花费很长时间来测试一些特性(几周!),同时批准其他应该在生产中部署的特性。

    我们处理这一问题的方法是正常使用Gitflow,并将Feature Toggles添加到我们的功能中。通过这种方式,我们可以将新的功能代码推送到生产中,但由于功能切换而处于非活动状态。我们可以使用财产文件配置功能是否处于活动状态(我们使用的是Togglz)。

    当然,所有“如果”的代码都会变得有点混乱,但好处是,如果已经在生产中但已禁用的功能获得批准,我们只需更改文件中的属性并重新启动应用程序,它就会变为活动状态,无需进行新的发布并在生产中安装!此外,Togglz有一个功能控制台(我们还没有尝试过),显然可以在运行时进行切换。

    您可以了解有关功能切换的更多信息 here . 你可以了解更多关于Togglz的信息 here here .

    我希望这有助于:)

        3
  •  0
  •   isaac-fisher    8 年前

    这还不够“git-flowy”。开发分支应该只包含获得其批准的特性——因此开发中的HEAD应该只包含经过测试并准备发布到主/生产的代码。
    解决这个问题的git流解决方案是,在完成功能的工作后,将其上传到origin(推送功能)并发送给测试人员(客户端?)。 只有在获得批准后,才会将其合并为开发。

    功能应该彼此独立,因此客户端可以按照自己的计划单独测试每个功能(*)。在流中,您可能将好代码和坏代码合并在一起,测试结果将无助于确定问题的来源。

    *)如果不是这样,或者您想并行测试特性,请使用集成分支。