2

I have come across a small issue with the git work flow in the team.

When starting to work on a user story, we create a feature branch from the develop branch. Once the user story is finished, a pull request is created and another developer completes the code review. Then the QA tests the feature on the feature branch.

Often it takes 1 day or more to merge the new feature in to develop branch from creating the pull request to finishing testing.

Problem comes when I start working on the next feature, which depends on previous feature which is still under testing. I cannot branch out from the develop because previous feature is not merged in to develop.

In that case, usually create feature branch from the other fearure branch instead of develop.

I would like to know whether this flow accepted and can be improved. Or is this just a communication issue?

Joshua
  • 129
  • 2

2 Answers2

2

That workflow seems a good match to your company's process, although people might take issue with parts of the process itself. One thing you might do to improve your workflow is to also merge develop into your new feature branch. That way you start locally integrating with other changes on develop sooner.

Also, if QA is testing for a day on every pull request, those pull requests might be getting somewhat large. You might consider doing a few smaller pull requests per user story, then handing off the completed user story to QA.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
0

Overall the process seems reasonable, but it doesn't seem like it will scale with either product complexity or team size.

The idea of creating a feature branch from the develop branch seems sound. This branching model is consistent with the gitflow model. There are a few related branching models that involve feature branching off of develop but vary in the use of master and release branches. I've had good successes with this type of approach overall, depending on the approach toward release and deployment.

I'm not sure that testing in the feature branch is where you want to be testing. I wrote about where QA should perform testing in an answer to a similar question. Just speaking generally, testing should happen twice - once in the feature branch to confirm that the added functionality is working as intended and once in the integration branch (develop, in this case) to ensure that the system remains stable. The question that remains is who does the testing in each place and what testing methodologies are used.

I can see some cases where you may need to branch off of a feature branch to continue working, but often this is a symptom of something else, such as architectural debt or not decomposing the work in the best way. This should be a rare event, not a regular occurrence.

The biggest concern that I have is the lack of automation testing in this whole process. By "automation testing", I'm referring to any tests that can be run in an automated process, from unit testing up to functional and acceptance testing. Manual testing is costly, especially as the system grows in complexity. My favored approach would be to start introducing test automation and including at least "happy-path" testing and regression testing as part of your pull requests and code reviews. The goal should be to find defects early as well as reduce the burden on QA manual testing.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283