19

Our team just made the switch from FogBugz & Kiln/Mercurial to Jira & Stash/Git. We are using the Git Flow model for branching, adding subtask branches off of feature branches (relating to Jira subtasks of Jira features). We are using Stash to assign a reviewer when we create a pull request to merge back into the parent branch (usually develop but for subtasks back into the feature branch).

The problem we're finding is that even with the best planning and breakdown of feature cases, when multiple developers are working together on the same feature, say on the front-end and back-end, if they are working on interdependent code that is in separate branches one developer ends up blocking the other.

We've tried pulling between each others' branches as we develop. We've also tried creating local integration branches each developer can pull from multiple branches to test the integration as they develop. Finally, and this seems to work possibly the best for us so far, though with a bit more overhead, we have tried creating an integration branch off of the feature branch right off the bat. When a subtask branch (off of the feature branch) is ready for a pull request and code review, we also manually merge those change sets into this feature integration branch. Then all interested developers are able to pull from that integration branch into other dependent subtask branches. This prevents anyone from waiting for any branch they are dependent upon to pass code review.

I know this isn't necessarily a Git issue - it has to do with working on interdependent code in multiple branches, mixed with our own work process and culture. If we didn't have the strict code-review policy for develop (true integration branch) then developer 1 could merge to develop for developer 2 to pull from. Another complication is that we are also required to do some preliminary testing as part of the code review process before handing the feature off to QA.This means that even if front-end developer 1 is pulling directly from back-end developer 2's branch as they go, if back-end developer 2 finishes and his/her pull request is sitting in code review for a week, then front-end developer 2 technically can't create his pull request/code review because his/her code reviewer can't test because back-end developer 2's code hasn't been merged into develop yet.

Bottom line is we're finding ourselves in a much more serial rather than parallel approach in these instance, depending on which route we go, and would like to find a process to use to avoid this.

Last thing I'll mention is we realize by sharing code across branches that haven't been code reviewed and finalized yet we are in essence using the beta code of others. To a certain extent I don't think we can avoid that and are willing to accept that to a degree.

fogwolf
  • 301
  • 2
  • 6
  • Just verifying - the code review is being done on the task merge to the feature? and there is no code review on feature merge to develop? –  May 27 '14 at 23:56
  • It depends. We have a rule of thumb that no Jira case that corresponds to a branch we directly check code into and that does not act as an "umbrella" case in a hierarchy sense takes more than 2 days. So if a feature case takes <=2 days, then there will be a code review to merge the feature to develop. If there are subtasks, once they are all merged into their feature ticket, someone does eyeball the pull request to merge that feature branch into develop, but not the same level of code review, since all the subtasks have already gone through that process. – fogwolf May 28 '14 at 13:13

4 Answers4

12

The issue might also lie in a too rigid separation of task between back-end and front-end development.

If a front-end developer need a new API, isn't it possible to allow him or her to create a dummy API on the back end (returning always the same value for example) to validate the layout ? Then commit that partial implementation with a stub, and in a second time, a back-end developer will implement the real feature.

By breaking the dependency, you will get a better flow and you don't have stop everything waiting for a single task that acts as a bottleneck.

Xavier T.
  • 1,612
  • 13
  • 15
  • I did think about this, but it's not part of our current development process and is extra overhead. I don't think the issue is entirely the front-end developer not being able to access the back-end developer's code to test during development, though. It's more about the code reviewers doing a smoke test of the entire integration (nothing mocked or stubbed) before we send it to QA. – fogwolf May 28 '14 at 13:08
  • 7
    While this is not part of your development process, is this any extra overhead than having two developers twiddle their thumbs for three days waiting on someone else to commit their code? You've got 8 hours of wasted developer time per thumb-twiddler. Compare that to the time it takes to stub out backend dependencies. – Greg Burghardt May 28 '14 at 19:37
6

Your problem: Developer A branches from Master, developer B branches from Master, both work on closely related features, and the inevitable fact that the merges into the Master branch are difficult because of inevitable conflicts is what holds everyone back.

If this is foreseeable, then A and B could first create a common branch, then each branch for their separate work from this common branch, merge each of their separate work into the common branch, and now you have a conflict free branch that is much easier to integrate.

gnasher729
  • 42,090
  • 4
  • 59
  • 119
0

If developer 1 works on feature A, and developer 2 finished working on feature B that depends on feature A, then there is no way around it - merging feature B is on hold. You can't test it without feature A, and there is no point in reviewing it yet since farther progress in feature A might lead to changes in feature B.

That does not mean, however, that developer 2 is on hold! Developer 2 can start working on feature C, and return to the review-fix cycle of feature B once feature A is complete. I know that context switching is not optimal, but since the time it'll take to complete feature A is probably measured in days it's not that bad(you are not pulling them out of "The Zone" for a 15 minutes side-task)

Idan Arye
  • 12,032
  • 31
  • 40
  • Sure, but this isn't quite the issue. It's more about for a single feature the process becomes a bit more serialized than it has to be. If we are scheduled to release a feature on x date, and the tickets can't be reviewed in parallel it is causing our estimates to off and potentially pushing out the release. – fogwolf May 28 '14 at 13:09
0

One thing you can do to help the situation is take a good look at ways to shorten the development cycle.

In the case where a developer is waiting on a feature from another developer, is there a way that a portion of the first developers work can go through review and integration prior to the entire feature to free up the block?

Are there ways to break features up into smaller units of work to keep the integration cycle going?

Also, how long does the integration take? If there's a long turn around on a build or integration, that can slow the entire queue. See if there's anything that you can do to speed up the build time so that the queues are freed up faster.

Steve Mitcham
  • 163
  • 6
  • This is what my main hopes are. I don't think we can eliminate the issue but by getting more comfortable with the new workflow I am hoping we will get better at planning and breaking down our work collaboratively within this new system to minimize the issue. Was just checking to see if anyone had run into anything similar, though, and had anything process-wise or related to the branching model we're using that could help. Thanks. – fogwolf May 28 '14 at 13:11