'Evergreening' - the process of upgrading your entire tech stack so that your infrastructure isn't running on years old versions of hundreds of applications and OS components with thousands of tens of thousands of CVEs.
Notice, in order to get to the evergreen state you need to do pre-evergreening, where you upgrade everything to current versions.
Then you apply your rolling or staged (e.g. quarterly) upgrade plans to keep everything evergreen.
This is, in theory, simple.
Unfortunately, Fox's Second Law https://gist.github.com/sleepyfox/b20579302ce05a9ac9f78c6003566989#foxs-second-law-of-software-development-difference-between-theory-and-practice
So there are all kinds of issues around dependencies between different software versions, and how many patch or minor versions of a system you can skip when upgrading, and how you test that the upgrades run your workloads in the same way they do currently, and...
Upgrade, release, test, upgrade again.
How much of this do you do for real vs. how much do you skip ahead on a test system.
How real is real-life?
Fox's Laws of Software Development

Fox's Laws of Software Development. GitHub Gist: instantly share code, notes, and snippets.

Gist
Am currently coming back from holiday to an #Evergreening project for a system with hundreds of clusters, thousands of #K8s hosts and tens of thousands of workloads, and wondering what new hellscapes the team will have uncovered in the last two weeks.
Once more into the breach!