Proper order of pull requests and testing

development-processpull-requestsqatesting

We want to setup proper development workflow.
We have two main branches: master(release branch) and develop(working branch).
We want to use pull requests properly.
We see two ways how to do this:

The first one:

  1. Create new branch for feature.
  2. Implement feature.
  3. Merge to develop branch.
  4. Test develop branch.
  5. Confirm that everything works.
  6. Create pull request onto master branch.
  7. Merge pull request.

Steps 4 and 7 can return to step 1.

The second one:

  1. Create new branch for feature.
  2. Implement feature.
  3. Create pull request onto develop branch.
  4. Merge pull request.
  5. Test develop branch.
  6. Confirm that everything works.
  7. Merge develop into master.

Steps 4 and 6 can return to step 1.

Which one is better? Or there is better way that I described?

We have 3 team members: developer, tester and reviewer.

Best Answer

The problem with the first approach is that features have to go through the developer's develop branch before they reach the shared repository. This means that if a developer has posted a pull request for a big and important feature that takes lots of discussing, reviews, approvals and changes, it'll clung their's develop branch and they won't be able to post smaller pull requests while waiting on other people actions/decisions related to that big PR.

Essentially - the local develop branch becomes a blocking bottleneck for each developer.

The problem with the second approach is that features are tested after they are merged into the shared repo's develop branch. This means you can have bad code in there that'll ruin the project for everyone until fixed. Also, if you decide to postpone or to abandon a feature because it's too hard to fix or because you can't fix it without ruining the overall design you need to change the shared repo's develop branch's history - which is not a very fun thing to do...

Essentially - the shared(!) develop branch becomes a blocking bottleneck for the entire team(!!).

So - I suggest a third approach, that avoids these problems:

  1. Create new branch for feature.
  2. Implement feature.
  3. Test feature branch.
  4. Create pull request onto develop branch.
  5. Merge pull request.
  6. Confirm that everything works.
  7. Merge develop into master.

That way, the blocking pipe is the feature branch - and since you can have as many as you want it's not a bottleneck.

Related Topic