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.
- master will be the source of truth and reflect current prod state.
- [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.
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.
- 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