7

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.

Improve this question
1
  • Note that the two approaches will result in two different types of history. In the first one, the develop and master branches could be very different, with master not having everything in develop and vice versa. You'll have to manage the synchronization to avoid pitfalls that come with this kind of setup. In the second one, you're safer because the master is always a subset of develop, if not equal.
    – ADTC
    Feb 9 at 8:42

2 Answers 2

Reset to default
17

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.

Improve this answer
6
  • 1
    What if developer implemented more than one feature. Should they be tested separately?
    – Sviatoslav Yakymiv
    Oct 8, 2014 at 12:44
  • 2
    Yes. Testing the features separately means you can merge them separately, so if one feature's test-fix cycle takes too long, the other feature that is already tested can be merged early.
    – Idan Arye
    Oct 8, 2014 at 13:59
  • What about regression testing? So tester should perform the same tests twice.
    – Sviatoslav Yakymiv
    Oct 8, 2014 at 14:07
  • Regression tests should be automated anyways. Every new feature has the potential of breaking any existing feature - it's impractical to check it manually for every new feature whether developers post pull requests one-at-a-time or multiple-at-once.
    – Idan Arye
    Oct 8, 2014 at 15:39
  • 1
    In ideal world yes. But we can not automate all tests. We are developing iOS application.
    – Sviatoslav Yakymiv
    Oct 8, 2014 at 15:47
6

I would say that whether you use the first approach ('you verify') vs. the second approach ('we verify') depends on the setup and organization of your team.

A small group of team members that work closely together (often in the same physical place but not always) often prefers the first approach.

A widely distributed team of folks who don't know each other well and that may work different hours and number of hours may prefer the second approach which gives more control to a central authority.

Improve this answer
4
  • What if we have three different persons: developer, tester, reviewer?
    – Sviatoslav Yakymiv
    Oct 8, 2014 at 12:11
  • Will the tester and reviewer be making code changes or do they just need to pull and use the code they are testing.
    – Michael Durrant
    Oct 8, 2014 at 12:35
  • Tester does not have access to the code. Reviewer does not write anything except comments. But reviewer and developer can swap their roles for other task.
    – Sviatoslav Yakymiv
    Oct 8, 2014 at 12:42
  • Yeah we do the role swapping also. So I would basic apply this principle to the role. If the people doing that role will be close at hand or more of the distributed model.
    – Michael Durrant
    Oct 8, 2014 at 15:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.