The way it used to work was that the upload went into a copy of the website, ideally created on a COW (copy-on-write) filesystem to avoid copying files that hadn’t changed and then you would change an alias or hard link to point to the new upload after confirming it was all there. Existing transactions would continue using the PHP code or whatnot stored in a cache (e.g. xcache or apc cache, but the new code could be read in and then new incoming requests could switch over so the new code starts serving new incoming requests when the new page cache is primed. Fancy configurations might use sessions for this, if there was shared session state to migrate. That said… most of the time, most folks didn’t think much of the occasional 500 as something new deploys. After all, you refresh and it’s gone, most of the time. And your internet or computer or browser is often as much to blame for problems as the website deploy, if it affects very few users during infrequent deploys of changed pages. The more fun task was what to do about database migrations. The traditional approach is “just take the site down for a minute, nobody cares,” as I said…
