Most PHP apps use a deployment method where a symlink gets set to a directory with a new version of the code. Because of how opcache works this has no impact on running requests, while new requests get handled with the new code.

Yes, my point really... it's really not "just upload files" like it's 1997.

That sounds pretty neat.

You can use the same strategy with PHP. Preload all your scripts in opcache. Once you're done making changes, reset your opcache.

In practice, any serious project is likely to be version-controlled. Git pull is generally fast enough that it behaves like an atomic change. (By default, opcache will not reload a file that's less than 2 seconds old.)

I'm pretty sure many PHP dev don't know about OPCache. Many of my colleagues don't know for sure. My point is "be aware of the state of your app code and what you execute", and so be aware of the shortcomings of this deployment "strategy". It's sure perfectly fine and easy for small apps / low traffic / not critical apps. I just want to point that it's not inherently good enough and definitely not the universal way to deploy a PHP app.

Git pull to deploy is something I avoid.

Yeah, I've seen cases where even git is not fast enough. That's when opcache preload comes into play. It's still better than manually uploading files over FTP.

Having said that, the "most modern" deployment strategy is to spin up a new container with your new code already loaded, point your LB at the new container, and scrap the old container. No opcache issues. No race condition.