Sorry, there is zero chance I will ever deploy new code by changing a symlink to point to the new directory.

I don't do devops/sysadmin anymore, so this would have been before the age of k8s for everything. But I once interviewed for a company hiring specifically because their deployment process lasted hours, and rollbacks even longer.

In the interview when they were describing this problem, I asked why the didn't just put all of the new release in a new dir, and use symlinks to roll forward and backwards as needed. They kind of froze and looked at each other and all had the same 'aha' moment. I ended up not being interested in taking the job, but they still made sure to thank me for the idea which I thought was nice.

Not that I'm a genius or anything, it's something I'd done previously for years, and I'm sure I learned it from someone else who'd been doing it for years. It's a very valid deployment mechanism IMO, of course depending on your architecture.

Why? What do you prefer to do instead?

why? it works and its super clever. Simple command instead some shit written in JS with docker trash

Works pretty well for Nix

Then you are locking yourself out of a pretty much ironclad (and extremely cost-effective) way of managing such things.

Isn't that the standard way to do that? Why wouldn't you?

that's how some phone OSes update the system (by having 2 read only fs)

that's how Chrome updates itself, but without the symlink part

Nobody's saying you should deploy code with this, but symlinks are a very common filesystem locking method.