1

In our current workflow, developers always create a new branch off of develop, work independently, push their changes to the remote development branch. Sometimes the work of one developer has a dependency on the work of another. In this situation, the developer whose work depends on the other will merge the feature branch with the needed code into their own, and develop against that. In an ideal world, they will remember to frequently pull from the other feature branch. The flow looks like this:

Our current git workflow

However, since the world is not ideal, sometimes we'll wind up with merge conflicts going into a release because the developers will have different versions of the dependent code in their branches, or worse there might be some "zombie code" laying around their branch. I'm thinking of proposing that in these situations where the work of one developer has a dependency on another, that we should treat the work as a single feature, and both devs should work off of the same branch, like this:

Proposed workflow change

However, I'm wondering if this is "best practice" or if it really confers a benefit as I think it does. How do others deal with this situation?

AlJones1816
  • 45
  • 7
  • Can you give us some examples on what kind of dependencies you are talking about. Is Dev 1 working on frontend while Dev 2 on backend ? Or both are working on backend developing services in parallel ? – sashok_bg Jun 15 '22 at 12:50
  • Both working on backend data processing. As a simple example dev1 is working on script a, and dev2's work needs script a as part of the process they're building in script b. e.g. script a is an API to extract data from some source. My proposed workflow also is that if the dependency is large the devs should coordinate to see if they should even be trying to work at the same time or if one piece belongs in a different sprint. – AlJones1816 Jun 15 '22 at 13:03

1 Answers1

3

This is how we managed these cases in our company:

  • The designated developers called the architect / tech lead
  • Together they first plan on a whiteboard the general solution, algorithms and domain separation
  • Then they do pair programming and sometimes even mob programming to put in place the "common" part of the code.

Most of the times these will be interfaces / abstract classes / swagger etc (there is a reason we also call interfaces 'contracts').

Once the interfaces and the common code has been developed it can be pushed to a branch feat/feature_name or release/v1.2.3 and then each developer can pull a branch from it and use mocking/stubbing strategies to advance on their side without actually having their partner's code ready. This is one of the most essential concepts of programming - abstraction, decoupling and cohesion.

Once finished - your merge back to the common feat branch and then your colleague can rebase to test the integration.

Speaking of integration - integration tests are really helpful in these situations.

PS: All of this is valid for a single feature team. If you have different feature teams and you have dependencies between the teams there are whole chapters in Eric Evans' DDD blue book on how to tackle it.

Hope this helps. Best Regards Alexander

sashok_bg
  • 2,436
  • 1
  • 22
  • 33