Branching strategy for multiple team working on same repository

Question

I am trying to come up with a branching strategy.

We have two teams working on the same product which is kept in one repository. Both teams have different release plans and if both teams merge on develop then it will be create or problems for another team to release as release branch created from develop will contain changes from other team.

Strategy that I am thinking is:

1. master will be the source of truth and reflect current prod state.

2. Both teams will have their own develop branch. team1-develop and team2-develop. Once a team wants to release they can create a release branch from their own develop branch and release on prod from the release branch, then release branch will be merged to master.

3. Other team will down-merge master to their develop to pull new release changes and keep their respective develop branches in sync with prod code.

Is this a good strategy? What can be other better solutions? Please guide.

Answer 1

Using branches can work for this kind of scenario, but when at least one of those two branches becomes very long-living, your setup may cause the need for large merges. Then one of yours team will run into trouble in case the area in code where they changed things is overlapping largely with the area where the other team worked.

The other alternative is to use only short-term branches, use only one main develop branch for both teams, but hide unfinished features which are not production-ready behind a feature toggle. That works best when the "feature entry point" is small, and checking the toggle is only required in one or two places. This should also be accompanied by a lot of testing, ideally automated regression testing, to reduce the risk one team accidentally breaks something visible outside the parts controlled by their feature's toggle.

But whatever you do, I think the crucial point is to make sure the major code areas where both teams work are separated. Ideally, they work on completely different components, with defined interfaces, and whenever an interface needs a change, they talk to each other.

Answer 2

Yes, that approach can be made to work.

It will need a suite of automated tests. Preferably running in some CI/CD environment. Everyone from both teams must be able to view recent test runs, and must care about clean test runs. Fix any rough edges in testing right away. It affects the sanity of your team, and of the other team.

1. master will be the source of truth and reflect current prod state.

Good!

2. [A team merges features to its own long-lived branch.] Once a team wants to release they can create a release branch from their own develop branch and release on prod from the release branch, then release branch will be merged to master.

That procedure might be a little too team specific, but perhaps I mis-read. At release time it shouldn't matter which team is releasing. Remember, the point of a develop integration branch is to coordinate feature releases so they can be tested prior to going live. The point of a master branch is to have a faithful record of what went live, so you can rapidly back out to a known good state.

It can take some variable amount of time for automated or human monitoring to notice that we went live on bad code. You want there to be one procedure for rolling back, rather than trying to figure out if the merge to master has happened yet, and if it proceeded smoothly without conflicts. Plus tagging releases will be much simpler with a uniform procedure.

Both teams will be keeping an eye on monitoring, diagnosing, and remediating any regressions that happen in production. All of those activities should happen w.r.t. master so you don't get per-team siloing and claims that "I can't do that since the change is over there on their branch."

Consider having a Release Team handle most changes to production, comprised of one individual from each team.

3. Other team will down-merge master to their develop to pull new release changes and keep their respective develop branches in sync with prod code.

It's a fact of life that merge conflicts happen. A "simulated developer" task running in CI/CD that pulls down merges is one way to build confidence that things are going smoothly and everyone is sticking to their respective sandbox. Merging mid-sprint, in the middle of developing a feature, is usually not a terrific plan as it sometimes becomes a distracting time suck. Finish the feature and then worry about a clean merge tends to be a better plan.

Here, we have a two-tier approach where e.g. team1's released edits will hit master, then team2-develop, and then appear in a newly created team2 feature branch. Recommend that you make the Release Team responsible for merging to develop branches, and for communicating the result.

Staggered release windows can help with coordination. If both teams are on two-week sprints, have them start in different weeks.

---

Use SemVer for your product releases.

Sometimes a released product is built from multiple in-house products, each of which bumps its version number independently. And of course there's always deps on external libraries, which rev on their own schedule and which your team will upgrade to, or not, on the team's preferred schedule.

It sounds like your teams are really quite separate. Each is responsible for a large chunk of code. See if there is 80% of some chunk that could be evicted into a separate repository. Now most of your coordination happens via packaged version releases, rather than via git merges.