-1

I work within a poly-repo that is worked on by multiple other teams, each in our own separate sections of this main repo.

I am coming to make my first push to production and I am unsure about strategies for doing so.

A traditional code-freeze on the Master branch isn't feasible due to the amount of teams and the frequency of code merging here.

One idea that was floated was making a copy of the current Master and as sub-master at the point where we have the code we want to be released. An issue I thought of with this was around any potential hot-fixes that might need to be made as a result of our production push from here... We can push fixes to the sub-master, however these wouldn't be replicated on the Master, so if all goes well in the re-testing of these hot-fixes, going back to work on the Master branch... They won't have been replicated and the issues in the initial cut of the sub-master will persist.

I created a diagram to try and help illustrate my point.

enter image description here

The traditional diagrams like this are a little confusing to me.

enter image description here

Any help or advice would be greatly appreciated.

physicsboy
  • 117
  • 2

1 Answers1

3

"Poly-repo" doesn't matter here, it just makes it more annoying as there are commits coming in that have nothing to do with your release schedule.

Your "sub-master" corresponds to what other people may call "staging" or "release candidate".

What's wrong with the classic release branch approach:

  • branch off master to release_1.0
  • tag that as release_1.0.0
  • test and deploy release_1.0. All teams can continue to commit to master
  • bug reports come in
  • fix bugs against master (VERY IMPORTANT)
  • you can then either port individual changes to release_1.0 branch and deploy tag release_1.0.1, or you can run the release cycle again and produce release_1.1
  • it is possible to do further emergency hotfix work as branches off release_1.0 called e.g. release_1.0_hotfix, but those MUST be merged back to master as soon as the situation has stabilized.

You should discourage "emergency" work in production as much as possible, preferring instead something like blue-green deployment where it's possible to abandon and reverse a deployment if problems are found.

pjc50
  • 15,223