3 ms·

> - Easy to deploy: Upload files, done. Sure, it works for simple/less important cases. But it also means that your application code is inconsistent while t

> - Easy to deploy: Upload files, done. Sure, it works for simple/less important cases. But it also means that your application code is inconsistent while the files are uploading. Stop your service, upload the files, start the service: safer. For a Django app you would upload files and ask Gunicorn to graceful reload... similar, just cleaner.

kijin 2y ago
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.)
- JodieBenitez 2y ago
  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.
  - kijin 2y ago
    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.
lenlorijn 2y ago
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.
- JodieBenitez 2y ago
  Yes, my point really... it's really not "just upload files" like it's 1997.
- dizhn 2y ago
  That sounds pretty neat.

kijin 2y ago

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.)

JodieBenitez 2y ago
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.
- kijin 2y ago
  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.

lenlorijn 2y ago

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.

JodieBenitez 2y ago
Yes, my point really... it's really not "just upload files" like it's 1997.
dizhn 2y ago
That sounds pretty neat.