i have been beating around this bush for eons and so far my best release strategy is custom build wordpress container where plugins and themes are built in.
The problem i was facing was mostly that almost all of the plugins used in "general", do not come with a testing architecture in any way. How are you going to handle a "rouge" plugin not closing its <div> tag correctly?
I used to have "hidden" control pages where i would render the most used elements with demo content which i could check against. But then you throw things like composer into the game and most of that goes out of the window.
After all these years, my best approach is still making a backup, hitting the upgrade button, and praying :/
Great question! Its one of the things where Im very curious to see if my plans hold up when they meet reality.
I plan to solve it my a mix of process and multiple environments:
0) Base assumption is that Im starting from a working site and everything that may break it is going to be a change to the working site.
1) Every live/prod site will have a test environment. Like test.example.com
2) (process) The customer that wants to change something will work in Test. Or me, if Im the one indtaling the plugins. Plugin(s) are installed/php changed and then verified to be working as intended in Test (manuals testing basically)
3) (process) Customer never works in prod.
4) (process) When the changes made in Test are working as expected, Ill then update the docker images used for prod with the (verified) working changes.
5) Deploy new images to prod in-actice site.
6) Switch active / in-active.
7) Verify updated live site works as intended. If not, switch back to previous active bringing the live site back online without errors and go back to step 2.
Its not going to be absolutely error free, nothing ever is, but the intention is to (a) minimize the number of errors by enforcing some process designed to promote quality[1], and (b) when something breaks it should be very fast to switch back to a working site, so error fixing dont need to be done in a rush because the (live) site is down.
1: Yes the process is old school compared to todays CI/CD pipelines and multiple deployments to prod each day, but that is not the goal nor the business needs. A stable working site is.
Edit: not sure I actually answered your question. A broken plugin (missing </div>) would never make it past step 2.
The problem i was facing was mostly that almost all of the plugins used in "general", do not come with a testing architecture in any way. How are you going to handle a "rouge" plugin not closing its <div> tag correctly?
I used to have "hidden" control pages where i would render the most used elements with demo content which i could check against. But then you throw things like composer into the game and most of that goes out of the window.
After all these years, my best approach is still making a backup, hitting the upgrade button, and praying :/