That's not true CI (by CI I mean development strategy, not tooling) because you have team branches meaning the teams' work is not integrated until merged into master - there are always teams whose work is not visible to other teams and which doesn't see work from other teams (thus open to the rebase/merge hell).
For true CI strategy all teams would work on master
(if really pulling task branches they'd be merged back into master very fast, not more than a few days lifespan) - everybody is practically on the same page.
A CI tool (and maybe a CD tool in a staging environment) would keep an eye on master
health.
Whenever master
is current release
-ready or when changes for the next release
start colliding with the current release
(release divergence) the current_release
branch is pulled and will never be merged back into master (such merges would be a big problem due to release divergence). Any bug fixes in current_release
(if applicable to master
as well) would be cherry-picked and double-committed (just because a fix is OK on one branch it doesn't mean it's OK on another branch).
The current_release
branch is practically your production branch. It needs it's own CI/CD setup, tailored on the current release
features. Production builds are just labels on this branch.
The master
branch continues to evolve towards next release
.
Rinse and repeat.
You can also have further sub-branches of current_release
for multi-level releases (major/minor/etc), which are also never merged back into their parent branch. The relationship between each such sub-branch and its parent is exactly as the relationship between current_release
and master
.