In 20 years I've never worked on a project that had a test suite strong enough to merit blind faith. Usually the weak points are

* realistic test input: either you carefully scrub actual production traffic and replay it (these require a ton of setup that doesn't age well), or you guess what you think users are doing and create dummy requests (and miss anything wacky you didn't know users do)

* load & perf: it's rare for a team to spin up a prod-sized cluster just for a test, and before AWS it was almost unheard of to go out and buy twice the hardware you need, even when you were lucky enough not to be deploying on your customer's boxes. A change that tanks your cache hit rate can ruin your whole day yet look fine at trivial sizes.

* visual design: Microsoft famously got bitten by moving away from manual testing that would catch dialogs made unusable by layout changes

We usually had best-effort integration tests, but they never caught everything, and we always had to make tactical decisions about when to release what based on risk.

* Lack of realistic test input is usually a problem caused by over-reliance on unit testing or lack of monitoring feedback.

* UX review and load & performance testing are usually things that we engage in regularly on trunk or the developer/code reviewer flags up ("this change has load implications/this change requires a UX review").

* "Microsoft famously got bitten by moving away from manual testing" - I'd never advocate eliminating manual testing entirely, just that it should be A) never repetitive, B) not a gatekeeper, C) always exploratory.

>We usually had best-effort integration tests, but they never caught everything,

Nothing ever catches everything but IMHO continuous delivery, short-lived branches, good monitoring and regular exploratory testing, load/perf testing on trunk is the best way to catch as much as possible.

I've started experimenting with integration tests that generate reports with screenshots and story steps, as well, so that there's a tighter UX feedback.

How do you support a 3 year LTS branch for enterprise customers without long lived branches?

IIUC your use case this is not the kind of branch that gets merged back, it's more of "another trunk" whose version is largely frozen and that may get backports and fixes.

I've done that. It signalled that the customer had a lack of faith in the stability of our releases.

In our case it was a valid concern (our team had a pretty awful track record).

Apparently you have never sold to a fortune 500? Many require bug fixes only of your app for X years. They don't care about new versions. Nothing about faith but about their priority. Using the latest and greatest is not their priority.

We were selling to Fortune 500s.

The upgrade paranoia only kicked in when they were subjected to broken releases and had to roll back.

The F500 is incredibly varied in their requirements even within the same company. I've seen demand for new features and long term, keep-everything-the-same-as-day-one from the same group for different services / products. Paying more money to keep things from not changing or for not adding features is something unique to enterprise environments though.

Well, sometimes the lack of stability is purposeful - new features are added, old features are deprecated, etc. How do you deal with that?

What languages do not support the equivalent of #ifdef in the C world, such that you can have variations in actionable code without having permanently separated code branches?

OP: this works for Google and Facebook, if you don't use it, you're dumb.

I'd quite like to load the LTS version of GMail and Facebook. I'd also like to have some say in how these apps I use every day work. Unfortunately, I have no say. I'm not even the customer.

Branch rot is a known problem, and it hints at a larger issue lurking somewhere in the organization - usually either inability to ship or inability to keep things in order.