I might be biased, but QA in Production [1] is my preferred approach now that we have great rollout systems [2][3] and ways to do verification testing in production [4].
[1] https://martinfowler.com/articles/qa-in-production.html
[2] https://split.io
The iron rule of software is that changes in the product have a reason behind them. If your UI tests break because of a structural change, that break should be anticipated while the corresponding story/feature is being developed.
In the past, when we faced test failures which seemed annoying and trivial, we discovered that the real reason why we never anticipated those failures was because we never know which tests to run for the feature or page in question. We are hoping to fix that by using robust, semantic tags for tests. So, where we used to have tags like @TC_123456 we now use tags like @Login_UI etc.