Git分支策略与测试/质量保证过程相结合 [英] Git branching strategy integated with testing/QA process

问题描述

我们的开发团队一直使用 GitFlow 分支策略，它一直很棒！

最近我们招募了几个测试人员来提高我们的软件质量。想法是每个功能都应该由测试人员测试/ QA。

过去，开发人员在不同的功能分支上处理功能，并将它们合并回到<$完成后c $ c>开发分支。开发人员将自己在特性分支上测试自己的工作。
$ b

测试人员应该在哪个分支上测试新功能？

很明显，有两种选择：

• li>
  
• 对开发分支

测试在开发分部

最初，我们相信这是一个可靠的方式，因为：

• 自从开发开始以来，该功能已与所有其他功能合并到 develop 分支中进行测试。


• 任何冲突都可以在以后检测到


• 它使测试人员的工作变得简单，他只处理一个分支（开发）。他不需要询问开发人员哪个分支是哪个功能的（功能分支是由相关开发人员完全自由管理的个人分支）
  
  
  

  最大的问题是：
  
  

  
  

  • develop 分支受到错误污染。
    
    

    当测试人员发现错误或冲突时，他会将其报告给开发人员，开发人员将问题修复到开发分支（功能分支在合并后放弃），以及之后可能会有更多修复程序。多个子序列提交或合并（如果重新创建分支开发分支以修复这些缺陷），可以从开发分支非常困难。在不同的时间，有多种功能可以合并到 develop 分支上进行修复。当我们想用开发分支中的一些功能创建一个版本时，这会产生很大的问题。

  

  
  
  

  测试特征分支

  
  
  

  所以我们再次考虑并决定测试特征分支上的特征。在测试之前，我们将来自 develop 分支的更改合并到功能分支中（赶上 develop 分支） 。这是很好的：
  
  

  
  
  • 您还在使用主流中的其他功能测试该功能
  
  
  • （例如错误修复，解决冲突）不会污染 develop 分支;
  
  
  • 您可以轻松决定不发布该功能，直到它已完全测试并获得批准;
    
  
  
  

  然而，存在一些缺点
  
  

  
  
  • 测试人员必须合并代码，如果有任何冲突（很可能），他必须向开发人员寻求帮助。我们的测试人员擅长测试，并且无法进行编码。
    
  • 某个功能可以在没有其他新功能的情况下进行测试。例如特征A和B同时处于测试中，这两个特征彼此不知道，因为它们都没有被合并到 develop 分支中。这意味着当两个特性无论如何都被合并到开发分支时，您将不得不再次对开发分支进行测试。如果功能A和功能B都经过测试和批准，但在合并冲突后，两个功能的开发人员都相信这不是他自己的错误/工作，因为他的功能分支通过了测试。沟通有额外的开销，有时解决冲突的人有时会感到沮丧。
  
  
  
  
  

  ---

  
  
  

  以上是我们的故事。由于资源有限，我想避免在任何地方进行测试。我们仍在寻找更好的方式来应对这一问题。我很想听听其他团队如何处理这种情况。

  解决方案

  我们这样做的方式如下： p>
  
  

  在我们合并最新的开发分支代码后，我们测试了功能分支。主要原因是我们不希望在功能被接受之前污染开发分支代码。如果某个功能在测试后不被接受，但是我们希望发布已经合并在开发中的其他功能，那将是地狱。 Develop是一个发布的分支，因此应该更好地处于可发布状态。长版本是我们在很多阶段进行测试。更多分析：
  
  

  
  
  1. 开发人员为每个新功能创建一个功能分支。
  
  
  2. 功能分支是（自动）部署在我们的TEST环境中，每次提交开发人员进行测试。
  
  
  3. 当开发人员完成部署并准备好测试功能时，他会合并功能分支上的开发分支，并部署包含TEST上所有最新开发更改的功能分支。
  
  
  4. 测试人员在TEST上进行测试。当他完成后，他接受了这个故事，并将这个功能分支合并到了开发中。由于开发人员之前已经将开发分支合并到了功能上，所以我们通常不会指望出现太多冲突。但是，如果是这种情况，开发人员可以提供帮助。这是一个棘手的步骤，我认为避免它的最好方法是尽可能保持特性尽可能小/特定。不同的特征必须最终以某种方式合并。当然，团队规模在这一步的复杂性上扮演着重要角色。
     
  5. develop分支也可以（自动）部署在TEST上。我们有一个策略，即使功能分支构建可能会失败，开发分支不应该失败。
  
  
  6. 一旦我们达到了功能冻结，我们就从开发中创建一个版本。这在STAGING上自动部署。在生产部署之前进行广泛的端到端测试。 （好吧，也许我夸大了一点，他们不是很广泛，但我认为他们应该是）。理想的beta测试者/同事，即真正的用户应该在那里测试。
  
  

  您如何看待这种方法？ b

  Our development team has been using the GitFlow branching strategy and it has been great !

  Recently we recruited a couple testers to improve our software quality. The idea is that every feature should be tested/QA by a tester.

  In the past, developers work on features on separate feature branches and merge them back to the develop branch when done. The developer will test his work himself on that feature branch. Now with testers, we start asking this Question

  On which branch should the tester test new features ?

  Obviously, there are two options:

  • on the individual feature branch
  • on the develop branch

  Testing On Develop Branch

  Initially, we believed this is the sure way to go because:

  • The feature is tested with all other features merged to the develop branch since it's development started.
  • Any conflicts can be detected earlier than later
  • It makes the tester's job easy, he is only dealing with one branch (develop) at all time. He doesn't need to ask the developer about which branch is for which feature ( feature branches are personal branches managed exclusively and freely by relevant developers )

  The biggest problems with this is:

  • The develop branch is polluted with bugs.

    When the tester finds bugs or conflicts, he reports them back to the developer, who fixes the issue on the develop branch (the feature branch were abandoned once merged ), and there could be more fixes required afterward. Multiple subsequence commits or merges (if a branch is recreated off develop branch again for fixing the bugs) makes rolling back the feature from the develop branch very difficult if possible. There are multiple features merging to and being fixed on the develop branch at different times. This creates a big issue when we want to create a release with just some of the features in the develop branch

  Testing On Feature Branch

  So we thought again and decided we should test features on the feature branches. Before we test, we merge the changes from the develop branch to the feature branch ( catch up with the develop branch ). This is good:

  • You still test the feature with other features in the mainstream
  • Further development ( e.g. bug fix, resolving conflict ) will not pollute the develop branch;
  • You can easily decide not to release the feature until it is fully tested and approved;

  However, there are some drawbacks

  • The tester has to do the merging of the code, and if there's any conflict (very likely), he has to ask the developer for help. Our testers specialize in test and are not capable of coding.
  • a feature could be tested without the existence of another new feature. e.g. Feature A and B are both under test at the same time, the two features are unaware of each other because neither of them has been merged to the develop branch. These means you will have to test against the develop branch again when both of the features are merged to the develop branch anyway. And you have to remember to test this in the future.
  • If Feature A and B are both tested and approved, but when merged a conflict is identified, both of the developers for both features believe it is not his own fault/job because his feature branch past the test. There is an extra overhead in communication, and sometimes whoever resolving the conflict is frustrated.

  ---

  Above is our story. With limited resource, I would like to avoid testing everything everywhere. We are still looking for a better way to cope with this. I would love to hear how other teams handle this kind of situations.

  解决方案

  The way we do it is the following:

  We test on the feature branches after we merge the latest develop branch code on them. The main reason is that we do not want to "pollute" the develop branch code before a feature is accepted. In case a feature would not be accepted after testing but we would like to release other features already merged on develop that would be hell. Develop is a branch from which a release is made and thus should better be in a releasable state. The long version is that we test in many phases. More analytically:

  1. Developer creates a feature branch for every new feature.
  2. The feature branch is (automatically) deployed on our TEST environment with every commit for the developer to test.
  3. When the developer is done with deployment and the feature is ready to be tested he merges the develop branch on the feature branch and deploys the feature branch that contains all the latest develop changes on TEST.
  4. The tester tests on TEST. When he is done he "accepts" the story and merges the feature branch on develop. Since the developer had previously merged the develop branch on feature we normally don't expect too many conflicts. However, if that's the case the developer can help. This is a tricky step, I think the best way to avoid it is to keep features as small/specific as possible. Different features have to be eventually merged, one way or another. Of course the size of the team plays a role on this step's complexity.
  5. The develop branch is also (automatically) deployed on TEST. We have a policy that even though the features branch builds can fail the develop branch should never fail.
  6. Once we have reached a feature freeze we create a release from develop. This is automatically deployed on STAGING. Extensive end to end tests take place on there before the production deployment. (ok maybe I exaggerate a bit they are not very extensive but I think they should be). Ideally beta testers/colleagues i.e. real users should test there.

  What do you think of this approach?

  这篇关于Git分支策略与测试/质量保证过程相结合的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！