Daily stabilization branches for releases - my experience

Context

In the context I am talking about, there was

• Scrum with multiple teams working on a trunk and temporary one additional release branch
• a build/deployment pipeline, where only good builds were picked / moved to the next stage in the pipeline.
  
• User Story acceptance could only be done on a stage, where the prerequisite / the criteria for a "good build" to be deployed on this stage was a green regression
• The regression test ran 1-3 times a day on the trunk and the release branch and was often red in the morning.

Results

The concept was tried and ... failed:

• Only 1/10 of the red regressions were green after fixing the tests on the stabilization branch (!)
• Several stabilization branches were thrown away due to the better test result in the release branch they were branched from!

The concept increased merge efforts:

• Downward merge rule: Stabilization Branch -> Branch -> Trunk

The concept led to huge confusion where to fix what and when to check in

• more confusion, less testing, more checkins during agreed check in stops (stop-the-line rule self by the teams)
• this lead to more red regressions and more broken builds.
  

The concept also violates the idea of continuous integration and is a real example of local optimization, which (even with good intensions) lead to bad results.

An article about Continuous Integration from Martin Fowler from 2006 can be found here