4

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?

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

  • Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask – gnat Oct 8 '14 at 10:22
  • 1
    @gnat have you read my question? I've posted two options that we found. – Sviatoslav Yakymiv Oct 8 '14 at 10:24
7

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.

  • What if developer implemented more than one feature. Should they be tested separately? – Sviatoslav Yakymiv Oct 8 '14 at 12:44
  • 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 '14 at 13:59
  • What about regression testing? So tester should perform the same tests twice. – Sviatoslav Yakymiv Oct 8 '14 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 '14 at 15:39
  • 1
    In ideal world yes. But we can not automate all tests. We are developing iOS application. – Sviatoslav Yakymiv Oct 8 '14 at 15:47
5

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.

  • What if we have three different persons: developer, tester, reviewer? – Sviatoslav Yakymiv Oct 8 '14 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 '14 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 '14 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 '14 at 15:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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