I work on an old monolithic system (20 years ish). It’s a case management system. We’ve been through many iterations of our workflow over the years I’ve worked there. Our current workflow is,

• Create a branch from main
• Create a PR against main when ready to merge
• Every night a new build of the program is automatically built and pushed to a testing environment
• Every Wednesday night we deploy a new version. We deploy the version that has been fully testet. So for instance, if we built v 9.101 on Tuesday night, but that build still has untested features, we deploy v 9.100 which was built Monday night, etc.
• If there is a major bug in production, we
  • temporarily deactivate merging.
  • fix the issue in main.
  • build a new version, push it out to a test environment
  • our product owners test the fix along with other new features that have found their way into the build.
  • Once testet ok, we decide if the fix is important enough to take the system down during working hours, or if it can wait for a night-time deploy.
  • We open up merging again.

The obvious down side to this way of working is that the product owners might have quite a few features to test if there is a hotfix, and other features have been merged since deploy. This has almost never been an issue though. We almost always deploy the very latest version on Wednesdays, and if there is a major issue, it’s usually discovered and reported before 11 am on Thursday. So the number of other features which have found their way into the code is usually 1 or 2 at the most. Each feature is usually quite small in scope, so it’s actually worked quite well for us.