0

I am working on a monolith codebase with multiple teams working on different folders/packages within the same codebase.

Now if you are working on a feature branch/fix branch you will first merge it into the test branch and then staging and then to live. This happens only when you are approved of course.

But the problem is if 2 teams are working on 2 different features and are deployed to staging already and one team is test ok on staging and the other is not ok, it's hard to deploy to live.

Right now the principle is staging is like live, you are always deployment ready in staging.

Is there any other good approach to this problem?

HexaCrop
  • 3,863
  • 2
  • 23
  • 50

1 Answers1

0

That is why you never merge integration branches: they include topic branches which are not always at the same maturity.

You merge the topic (feature branch/fix branch) itself to your integration branches (first to test, then the same topic to staging, then the same topic to live)

It is called gitworkflow (one word).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • so basically, all 3 of the integrations branch doesn't have a connection between them right? – HexaCrop Nov 14 '22 at 08:52
  • Also is there any other ways we could solve this? Like multiple approvers or things like that? – HexaCrop Nov 14 '22 at 08:54
  • 1
    @HexaCrop Not that I know of. Once your branches are merged into one integration branch, it becomes very difficult to do a partial merge of said integration branch to another one. – VonC Nov 14 '22 at 10:12